ДИНАМИЧЕСКАЯ АКТИВАЦИЯ УСЛУГ М2М ЧЕРЕЗ СЕТИ ДОСТУПА 3GPP Российский патент 2017 года по МПК H04W4/00 

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ

Данная заявка испрашивает приоритет по предварительной заявке США № 61/510,301, поданной 21 июля 2011 года, и предварительной заявке США № 61/508,243, поданной 15 июля 2011 года, содержание которых целиком включено в данный документ по ссылке. Данная заявка является родственной по отношению к принадлежащей заявителю настоящей заявки патентной заявке США под заголовком «M2M Services Enablement Architecture for Cellular Access Network», имеющей порядковый номер 13/517,790.

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

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

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

Межмашинная (M2M) связь включает в себя связь (с использованием проводных или беспроводных средств или их комбинации) между двумя машинами без вмешательства человека. Заметим здесь, что термин «M2M связь» в некоторых литературных источниках аналогичен термину «машинная связь (MTC)». Однако для обеспечения непротиворечивости в данном описании используется только термин «M2M связь». Некоторыми примерами M2M связи являются: интеллектуальные измерения (например, дистанционное считывание показаний счетчиков коммунальных услуг), контроль состояния пациентов (например, дистанционный контроль частоты сердечных сокращений пациента), сельскохозяйственный мониторинг (например, контроль состояния посевов сельскохозяйственных культур), отслеживание состояния транспортных средств автомобильного парка (например, текущий контроль грузовых автотранспортных средств на дороге), контроль безопасности (например, автоматический контроль в режиме реального времени параметров безопасности в здании или комплексе зданий), управление счетами по транзакциям и управление запасами (например, посредством текущего контроля транзакций в точках продаж в супермаркете) и т.д. В этих вариантах M2M связи, как правило, используются датчики, способные передавать данные, или диагностические устройства (которые могут выполнять измерения, текущий контроль и т.д., упомянутые ранее) на одном конце и пользовательское устройство или приемник M2M системы на другом конце для приема данных (например, беспроводным образом через сотовую сеть доступа, как обсуждается ниже со ссылками на фиг. 1) от устройств-датчиков и обрабатывать данные согласно требуемой M2M услуге (например, услуга измерения потребляемых коммунальных ресурсов, услуга контроля состояния пациентов, услуга подготовки счетов и т.д.).

Все услуги из огромного числа различных M2M услуг используют некоторые общие служебные средства (SC) M2M, такие как SC, относящиеся к маршрутизации, обеспечению безопасности, распределению соответствующих ресурсов, обнаружению и достижимости других объектов в облаке (например, сеть оператора) и т.д. Эти служебные средства M2M обычно используются всеми очень разными M2M услугами (например, в пользовательских устройствах M2M связи, в сети поставщика M2M услуг (SP) и т.д.) при осуществлении связи с сервером (AS) M2M приложения (приложений) в сети поставщика M2M услуг (SP).

В общем случае M2M связь также может называться M2M услугами, которые привязаны к «уровню услуг», в то время как сотовая сеть доступа (AN) (которая более подробно обсуждается ниже) может предоставлять «транспортный уровень» для M2M связи. Чтобы любая архитектура для активации M2M услуг функционировала с большой гибкостью и имела возможность предоставлять M2M услуги бесплатно и независимо от оператора сети доступа, возможно окажется предпочтительным, чтобы в любой такой архитектуре для активации M2M услуг транспортный уровень (на основе AN) и уровень услуг (на основе SP) были разделены. Имея в виду это предпочтение, Технический комитет по M2M связи Европейского института стандартов электросвязи (далее «ETSI M2M TC») провел исследование по определению архитектуры уровня услуг (SL) M2M, базирующееся на следующих основных принципах:

(I) Общие аспекты: (а) архитектура для активации M2M услуг не зависит от типа доступа (то есть существенно не зависит от базовой технологии сотовой сети AN); (b) слабая связь между транспортным уровнем и уровнем услуг; (с) при перемещении из одной сети доступа в другую не требуется изменения M2M услуг; (d) одновременный доступ к одному и тому же уровню M2M услуг из разных сетей доступа.

(II) Аспекты, относящиеся к доступу и устройствам: Архитектура для активации M2M услуг поддерживает следующие типы устройств: (а) M2M устройство прямого доступа, которое поддерживает прямой доступ к сотовой сети; (b) M2M шлюз, который поддерживает доступ к сотовой сети M2M устройствами доступа (обсуждаются ниже), подсоединенными к сети. Этот шлюз может работать в качестве концентратора (например, концентратора данных, полученных от множества подсоединенных устройств непрямого доступа); (с) M2M устройство непрямого доступа, которое подсоединено к M2M шлюзу и которое не поддерживает прямой доступ к сотовой сети.

(III) Сетевые аспекты: В архитектуре для активации M2M услуг заложено следующее: (а) разделение транспортного уровня и уровня услуг (настолько, насколько это возможно); (b) M2M услуги могут предлагаться независимо от конкретного оператора сети доступа; (с) определено, что общие служебные средства (SC) M2M используются всеми M2M приложениями. Эти общие M2M SC могут быть развернуты отдельно от конкретного сервера приложения (приложений) (AS).

На фиг. 1 показана существующая архитектура 10 для активации M2M услуг с использованием сотовой сети 12 доступа. В архитектуре 10 на фиг. 1 показана сотовая сеть AN 12, соединенная с сетью 14 поставщика M2M услуг (SP) с учетом вышеупомянутых трех принципов, определенных Техническим комитетом института ETSI (далее ETSI M2M TC). Для удобства и облегчения понимания сути обсуждения термины «сеть доступа» или «транспортная сеть» можно использовать здесь так, чтобы они включали не только часть сети радиодоступа (содержащую, например, базовую станцию с или без контроллера базовой станции) сотовой сети оператора, но и другие части (например, сотовую транзитную и базовую сеть). Аналогичным образом, термины «поставщик M2M услуг» или «M2M SP» и «сеть M2M SP» могут использоваться здесь как взаимозаменяемые при ссылках на сеть 14 M2M SP (и другие аналогичные сети, показанные здесь на других фигурах и обсуждаемые ниже). Возможно, что поставщик M2M услуг также является оператором или поставщиком услуг сотовой сети AN 12. С другой стороны, поставщик M2M SP может не зависеть от поставщика услуг сотовой сети AN, но может иметь деловые взаимоотношения с оператором сотовой сети в межкорпоративных целях.

Как показано на фиг. 1, сотовая сеть AN 12 может включать в себя множество сотовых участков 16-18, каждый из которых находится в зоне покрытия радиосвязью соответствующей базовой станции (BS) или базовой приемопередающей станции (BTS) 20-22. Эти базовые станции 20-22 могут беспроводным путем принимать передачи (как показано линиями 23А-23С радиосвязи) от различных объектов 24-32 M2M связи (подробно обсуждаемых ниже со ссылками на фиг. 2), работающих в домене 34 M2M устройств и направлять принятые данные в часть 36, являющуюся M2M ядром сотовой сети 12. M2M ядро 36 может включать в себя сотовую транзитную часть 38 и сотовую базовую сеть (CN) 40. В случае использования, например, базовой станции 20-22 3-го поколения (3G) сотовая транзитная часть 38 может содержать функциональные средства 3G контроллера радиосети (RNC) или контроллер базовой станции (BSC). Можно считать, что части транзитной подсистемы 38 (такие как, например, контроллеры BSC или RNC) вместе с базовыми станциями 20-22 содержат часть RAN сети 12. Примеры указанных сетей RAN включают в себя универсальные наземные сети радиодоступа (UTRAN); усовершенствованную сеть UTRAN (E-UTRAN); сеть GSM/EDGE RAN (GERAN), где «GSM» относится к Глобальной системе мобильной связи, а «EDGE» относится к усовершенствованной технологии с повышенной скоростью передачи данных для развитых систем GSM; системы, где используется технология глобальной совместимости в микроволновом диапазоне (WIMAX) на основе стандарта IEEE 802.16е. Института инженеров по электротехнике и электронике (IEEE); и т.д. С другой стороны, базовая сеть (CN) 40 может обеспечить: логические, сервисные и управляющие функции (например, управление счетами абонентов, выписка счетов, управление мобильностью абонентов и т.д.); связность по протоколу Интернет (IP) и соединения с другими сетями (например, Интернет) или объектами; поддержку роуминга и т.д. Сетью CN 40 может быть, например, сеть CN Проекта партнерства третьего поколения (3GPP), сеть CN Проекта 2 партнерства 3-го поколения (3GPP2) (для сотовых систем с множественным доступом и кодовым разделением каналов (CDMA)), либо сеть CN типа ETSI TISPAN (TIPHON (Телекоммуникации и гармонизация протокола Интернет (по сетям) и SPAN (Услуги и протоколы для усовершенствованных сетей)).

Как упоминалось ранее, предложенная институтом ETSI архитектура для активации M2M услуг (такая как архитектура 10 на фиг. 1) базируется на общем приложении 42 для активации M2M SC (например, услуг, относящихся к маршрутизации, безопасности и т.д.), которые определены для использования всеми M2M приложениями. Это приложение для активации средств M2M SC (называемых здесь просто «M2M SC») может обеспечить функции M2M связи, которые доступны для совместного использования различными M2M приложениями (независимо от того, находятся ли они на сервере M2M AS 44 или на объекте 50 M2M связи, показанном на фиг. 2 и обсуждаемым ниже) и раскрывает эти функции через набор открытых интерфейсов (не показаны). Средства M2M SC 42 могут использовать функциональные средства базовой сети в ходе упрощения и оптимизации разработки и разворачивания M2M приложения посредством скрытия сетевых особенностей. Различные M2M приложения обеспечивают программный код, который после его выполнения соответствующими объектами M2M связи или пользовательским устройством могут предоставить M2M услуги, характерные для конкретного приложения, такие как услуга интеллектуального измерения, услуга контроля состояния пациентов и т.д., которые обсуждались ранее. Соответствующие части M2M SC 42 могут находиться на каждом объекте M2M связи (как показано, например, на фиг. 2), а также в пользовательском M2M устройстве 44. Таким образом, M2M приложение (например, M2M приложение 52 на фиг. 2) может выполнять комплекс логических операций (не показаны) и использовать соответствующие средства M2M SC (например, M2M SC 54 на фиг. 2), доступные через открытый интерфейс, для способствования предоставления M2M услуги, поддерживаемой M2M SP 14. Средства M2M SC 42 могут взаимодействовать с сервером 46 M2M приложения (приложений) в M2M SP 14, используя подходящий интерфейс прикладного программирования (API) (который может включать в себя полный интерфейс, единственную функцию или набор интерфейсов API, характерных для приложения), чтобы тем самым способствовать предоставлению различных M2M услуг, связанных с M2M приложениями, поддерживаемыми поставщиком 14 M2M услуг.

На фиг. 1 также показан M2M пользователь 44 (который также называется здесь «пользовательским M2M устройством», а также может называться «MTC пользователем» в некоторых литературных источниках) в связке с сервером M2M AS 46. M2M пользователь 44 может представлять собой устройство, способное функционировать в системе MTC связи, осуществляя связь с различными объектами 24-32 M2M связи в домене 34 M2M устройств и может (дистанционно) управлять ими или приводить их в действие. Например, если объектом M2M связи является датчик или блок контроля за состоянием здания, то в этом случае M2M пользователем 44 может быть удаленный блок сбора/обработки данных, который может подавать на указанный датчик контроля команды на передачу данных контроля с заранее определенными временными интервалами (с тем, чтобы, например, не перегрузить ресурсы сотовой сети или предотвратить случайный доступ объекта M2M связи к средствам M2M SC 42). Комбинация M2M AS 46 и M2M SC 42 может способствовать пересылке соответствующих данных, характерных для конкретного приложения, или другого контента между M2M пользователем 44 и соответствующим объектом/объектами M2M связи в области 34 M2M устройств.

На фиг. 2 показана логическая блок-схема существующего объекта 50 M2M связи, который может базироваться в домене 34 M2M устройств. Объектом 50 M2M связи может быть M2M устройство прямого доступа, M2M устройство непрямого доступа или M2M шлюз, которые упоминались ранее. Например, в конфигурации на фиг. 1 каждый из объектов 24-25 M2M связи (например, устройства отслеживания автотранспортного парка или управления маршрутизацией) может представлять собой M2M устройство прямого доступа, в то время как каждый из объектов 27-32 M2M связи может представлять собой M2M устройство непрямого доступа (например, датчики контроля за состоянием здания), находящееся на связи с M2M шлюзом, который может функционировать в качестве концентратора данных, принимаемых от различных M2M устройств непрямого доступа. Некоторые из объектов 27-32 M2M связи могут быть соединены друг с другом, с другими подобными объектами (не показаны) или с одним или несколькими M2M шлюзами (например, M2M шлюз 26) через локальные M2M сети 47-49, которые могут представлять собой сети стандарта IEEE 802.15.1, Bluetooth® или другие подобные локальные сети. В некоторых случаях объект M2M связи может осуществлять доступ к сотовой сети 12 через одну или несколько указанных локальных M2M сетей 47-49.

В обсуждении, представленном ниже, термины «объект M2M связи», «M2M объект» и «M2M устройство» могут использоваться как взаимозаменяемые для облегчения обсуждения. Например, в зависимости от контекста термин «M2M устройство» может относиться к M2M устройству (независимо от того, является ли это устройство устройством прямого доступа или непрямого доступа) или к M2M шлюзу, либо к тому и другому. Однако, если из контекста следует иное, устройство и шлюз могут быть определены отдельными терминами, а не посредством общих терминов «M2M объект» или «M2M устройство». Кроме того, заметим, что объект M2M связи или устройство 50 может представлять пользовательское оборудование (UE) или мобильную станцию (MS) (также известные под различными аналогичными терминами, такими как «мобильная трубка», «беспроводная трубка», «беспроводное устройство», «терминал» и т.д.), сконфигурированные должным образом для реализации M2M связи. Некоторые примеры указанных мобильных трубок/устройств включают в себя сотовые телефоны или оборудование для пересылки данных (например, персональный цифровой помощник (PDA) или пейджер), смартфоны (например, iPhone^TM, Android^TM, Blackberry^TM и т.д.), компьютеры, устройства Bluetooth® и т.д.

Как показано на фиг. 2, M2M объект или устройство 50 может включать в себя M2M приложение (приложения) (или программный код) 52, характерное для устройства, и средства M2M SC 54, характерные для устройства. Таким образом, M2M устройство 50 выполняет M2M приложение (приложения) 52, используя свои собственные средства M2M SC 54 для предоставления M2M услуги (услуг) (например, M2M пользователю 44), для которого оно разработано или сконфигурировано. В приведенном ниже обсуждении, когда объектом 50 M2M связи является M2M устройство (независимо от того, является ли оно устройством прямого доступа или непрямого доступа), указанные средства SC, характерные для устройства, могут называться «D-SC», а когда M2M объектом 50 является M2M шлюз, указанные SC, характерные для устройства, могут называться «G-SC», чтобы различать средства SC в M2M устройствах и M2M шлюзах. В приведенном ниже обсуждении может быть использован вариант сокращения «D/G-SC» для обозначения обеих указанных средств SC вместе. Можно считать, что M2M устройство 50 поддерживает логический доступ к сотовой сети 12 (например, доступ 3GPP), как если бы существовала комбинация из двух логических M2M устройств: M2M устройства 56 доступа/транспортировки и устройства 58 M2M услуг. (Хотя для краткости здесь это не всегда упоминается, понятно, что, когда M2M объектом 50 является M2M шлюз, то ссылочные позиции «56» и «58» могут относиться соответственно к шлюзу M2M доступа/транспортировки и шлюзу M2M услуг). Устройство 56 M2M доступа/транспортировки может поддерживать все аспекты интерфейса радиодоступа 3GPP и сети доступа 3GPP. С другой стороны, устройство 58 M2M услуг может поддерживать все аспекты, которые относятся к уровню услуг (SL) M2M. Такая логическая конфигурация может отражать ранее упомянутое разделение между транспортным уровнем и уровнем услуг. Таким образом, устройство 56 M2M доступа, например, может иметь идентификатор (для доступа на транспортном уровне к сотовой сети 112), который отличается от идентификатора устройства (который использован на уровне услуг) для устройства 58 M2M услуг. Кроме того, устройство 58 M2M услуг включает в себя идентификатор M2M приложения (не показан) и идентификатор подписки на M2M услуги (не показан) для выполнения операций уровня услуг, в то время как устройство 56 M2M транспортировки может содержать идентификатор подписки на сеть M2M доступа (не показан) и сетевой адрес M2M доступа (не показан) для поддержки интерфейса доступа сотовой сетью 12 доступа с использованием транспортного уровня. Таким образом, в случае использования одного M2M приложения одна часть этого приложения может находиться на M2M AS 46, в то время как соответствующая ей часть может находиться на M2M объекте 50 (как часть M2M приложения (приложений) 52). В этой связи, устройство 58 M2M услуг может выступать в качестве хост-устройства для части указанного приложения, характерной для M2M объекта, и может использовать устройство 56 M2M доступа для доступа к серверу M2M AS 46 в сети 14 поставщика услуг, используя сотовую сеть 12 для транспортировки.

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

Из приведенного выше обсуждения очевидно, что Технический комитет ETSI M2M TC определяет архитектуру уровня услуг (SL) M2M, независимую от типа доступа (то есть архитектуру, показанную на фиг. 1 и более подробно обсуждаемую в документе «Техническая спецификация (TS) 102.69 Института ETSI» под заголовком «Межмашинная связь (M2M); Функциональная архитектура»), так что поставщик M2M SP может предлагать M2M услуги независимо от конкретного типа сети доступа, используемой объектом M2M связи. Другими словами, архитектура ETSI M2M TC обеспечивает стандарт на уровне услуг (SL) независимо от уровня (транспортного уровня или уровня доступа). Однако в настоящее время отсутствует архитектура активации согласно ETSI TC 102.69, которая четко определяет «объединенные» или «взаимодействующие» версии архитектур (сотового) транспортного уровня и уровня M2M услуг таким образом, который позволяет использовать сотовую сеть AN для активации общей архитектуры M2M услуг, которая в основном согласуется с принципами архитектуры ETSI M2M SL (специфицированной в вышеупомянутом документе ETSI TC 102.69) при одновременной возможности у сотовой сети AN осуществлять необходимый контроль за использованием своей сети. Здесь термин «общий» обозначает, что архитектура M2M SL не зависит от типа доступа (то есть общая архитектура SL, которая может функционировать вместе с множеством различных сетей доступа на основе Протокола IP, таких как сети 3GPP, 3GPP2, LTE (Проект долгосрочного развития), EV-DO (развитая технология оптимизированной передачи данных), UMTS (Универсальная система мобильной связи), технология Форума с ограниченным доступом, GPRS (Пакетная радиосвязь общего пользования) и CDMA 2000 (Множественный доступ с кодовым разделением каналов).

С другой стороны, хотя Рабочая группа 2 разработчиков архитектуры систем 3GPP (SA2) идентифицировала некоторые аспекты активации M2M архитектуры в сотовой сети доступа 3GPP (в конфигурациях под управлением сети AN или под управлением поставщика SP), в этой архитектуре группа 3GPP SA2 не определила, каким образом разные сети доступа и сети поставщика M2M услуг будут взаимодействовать для обеспечения современного технического решения, которое даст возможность сотовой сети доступа получить информацию о типе M2M услуг, которые предлагаются в добавление к транспортировке сетью доступа. Например, в документе 3GPP SA2 не рассмотрены следующие случаи:

(1) Каким образом сеть доступа 3GPP, которая разворачивает средства M2M SC в сети доступа оператора, сможет взаимодействовать, обслуживать и осуществлять связь с сетью поставщика M2M услуг (SP), которая также разворачивает средства M2M SC в своей сети.

(2) Когда M2M устройство находится в роуминге в гостевой сети доступа, которая разворачивает средства M2M SC, каким образом можно использовать домашнюю сеть доступа для разрешения гостевой сети доступа направлять некоторые M2M услуги непосредственно в сеть M2M SP, когда другие M2M услуги направляются через домашнюю сеть доступа.

(3) Каким образом сеть доступа 3GPP, которая разворачивает средства M2M SC в соответствии с архитектурой ETSI M2M SL, сможет предлагать услуги другим поставщикам M2M услуг, которые разворачивают другую архитектуру M2M SL (то есть архитектуру, не соответствующую ETSI M2M SL). Указанная архитектура, не соответствующая ETSI M2M SL, может здесь называться по-разному: «другой уровень M2M услуг», «другие M2M услуги», «другой M2M SL» или «M2M SL-OTH».

(4) Каким образом сеть доступа 3GPP, независимо от места разворачивания M2M SC, сможет предоставить возможность использования своих услуг транспортировки, когда сеть доступа не имеет соглашения об использовании уровня услуг (SLA) с поставщиком услуг M2M SP.

(5) Каким образом сеть доступа 3GPP, которая не разворачивает средства M2M SC, сможет взаимодействовать, обслуживать и осуществлять связь с сетью M2M SP, которая также не разворачивает средства M2M SC в своей сети.

Рабочая группа 3GPP2, как и рабочая группа 3GPP SA2 также предпринимает попытки (например, в своем докладе X.P0067-0 под заголовком «Machine to Machine Architecture and Enhancement Study for cdma2000 Networks») точно определить архитектуру активации M2M услуг, которая использует сети доступа 3GPP2 (на основе CDMA) для предоставления M2M услуг, соответствующих архитектуре ETSI M2M SL и любой другой архитектуре M2M SL. Однако архитектура 3GPP2 также не учитывает вышеупомянутые случаи (перечисленные в контексте 3GPP SA2).

Другой проблемой, которая не была решена в существующих технических решениях, является то, каким образом поставщик M2M услуг может использовать множество IP адресов для продвижения своих услуг. Например, поставщик услуг M2M SP, который использует доступы 3GPP, 3GPP2 и фиксированный IP доступ для поддержки своих услуг.

В настоящее время традиционное техническое решение, касающееся предоставления M2M услуг, которое используется сетями доступа 3GPP, прописано нечетко, и не привязано к конкретной детально определенной архитектуре M2M SL (такой как архитектура M2M SL, определенная в документе ETSI TS 102.69). В существующих запатентованных технических решениях или решениях, характерных для оператора, не используется концепция общих средств M2M SC. Наоборот, в упомянутых технических решениях используется индивидуальный подход для каждого M2M приложения, в результате чего попытка идентифицировать общую (то есть «универсальную», или независимую от типа доступа) архитектуру M2M SL, которая может быть использована любой сетью доступа для всех M2M приложений.

В этой связи, желательно найти обобщающее техническое решение, касающееся того, каким образом предоставить сотовой сети AN возможность использовать активацию общей архитектуры M2M услуг, которая в основных своих аспектах соответствует принципам, заложенным в основу архитектуры ETSI M2M SL (например, разделение транспортного уровня и уровня услуг, общие средства M2M SC, используемые всеми M2M приложениями, и т.д., как обсуждалось ранее), и одновременно разрешить оператору сотовой сети AN осуществлять соответствующий контроль за использованием своей сети. Другими словами, желательно активировать сотовую сеть AN для предоставления ее конкретных услуг (например, транспортных услуг) для любых M2M услуг, при одновременной поддержке исполнения соглашения об использовании уровня услуг (SLA) для сбора соответствующей информации тарификации, чтобы запланировать необходимые организационные и управленческие средства для предлагаемых M2M услуг и т.д.

Кроме того, для указанной общей архитектуры активации M2M услуг, которую можно успешно использовать с различными вариантами сотового доступа, например, поддерживающими архитектуру сети доступа 3GPP и базовую сеть (CN), также желательно найти детальное техническое решение, которое определит следующие вопросы взаимодействия уровня услуг и транспортного уровня.

(а) Способность сети доступа 3GPP получать информацию (предпочтительно в динамическом режиме) о межуровневом (A-Layers) идентификаторе M2M устройства/шлюза (который может совпадать с так называемым «внешним идентификатором M2M устройства/шлюза», как правило, используемым объектами (например, сервером средств M2M SC в сети поставщика услуг M2M SP), которые являются внешними по отношению к сети 3GPP, для идентификации M2M устройства/шлюза, которое используют для MTC в системе 3GPP). Указанный «внешний» идентификатор можно отличить от «внутреннего» идентификатора, являющегося идентификатором, относящимся к подписке, который используют в системе 3GPP для уникальной идентификации объекта M2M связи, используемого для MTC. Этот «внутренний» идентификатор не обязательно может быть известен объектам, являющимися внешними по отношению к сети 3GPP. В данном обсуждении в качестве параметра (например, идентификатора устройства/шлюза) или информации рассматривается так называемый «межуровневый» или «A-Layers» параметр/информация, когда этот параметр/информация необходим для активации M2M услуг транспортного уровня и уровня услуг. Для удобства обсуждения термин «межуровневый идентификатор M2M устройства» иногда используется здесь для ссылки на межуровневый идентификатор M2M устройства и/или шлюза.

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

(b) Способность сети доступа 3GPP отображать межуровневый идентификатор M2M устройства/шлюза на подписку на доступ 3GPP и идентификатор подписки на доступ 3GPP.

(с) Способность сети доступа 3GPP правильно идентифицировать и отображать IP трафик, поступающий от различных сетей M2M SP в направлении одного и того же устройства M2M доступа (устройство 56 M2M доступа, показанное на фиг. 2).

(d) Способность сети доступа 3GPP правильно определить достижимость устройства M2M услуг (например, устройство 58 M2M услуг, показанное на фиг. 2) на основе трафика, который посылается на конкретный межуровневый идентификатор M2M устройства, конкретные средства M2M D/G-SC и/или конкретное M2M приложение.

(e) Способность сети доступа 3GPP узнавать тип M2M приложения, которое выполняется, в добавление к устройству M2M доступа, используемого устройством M2M услуг. Это может потребоваться для того, чтобы сеть доступа 3GPP идентифицировала должное качество обслуживания (QoS), которое необходимо для конкретного M2M приложения.

(f) Способность сети M2M SP посылать трафик на конкретное устройство M2M услуг, конкретные средства M2M D/G-SC и конкретные M2M приложения.

(g) Способность сети M2M SP конфигурировать объект M2M связи с надлежащим межуровневым идентификатором M2M устройства/шлюза во время начального подключения для первого обслуживания к сети SP. Как упоминалось выше, в подразделе (а), предпочтительным является динамическое решение этой проблемы. Это решение должно гарантировать, что межуровневый идентификатор средств M2M D/G, сконфигурированный сетью M2M SP, также доступен сети AN 3GPP и является уникальным в сети AN 3GPP.

(h) Сеть M2M SP должна иметь информацию о подписке на M2M услуги, которая авторизует устройство/шлюз M2M услуг, для приема идентифицированной M2M услуги.

(i) Возможность при использовании этого технического решения предоставлять одновременный доступ к одной и той же подписке на M2M услуги из разных сетей доступа при обеспечении правильной идентификации и разделения разных трафиков, проходящих по указанным разным сетям доступа.

Конкретные варианты настоящего изобретения обеспечивают решение вышеупомянутой проблемы разработки общей архитектуры активации M2M услуг (которая основана на принципе разделения уровня услуг и транспортного уровня, предложенном институтом ETSI) на основе нижеследующих положений.

(I) Использование M2M прокси-модуля. Этот подход позволяет оператору сотовой сети AN не только разворачивать свои средства M2M SC, как это делает сервер средств M2M SC в своей сетевой области, но также использовать свои M2M SC для функционирования в качестве прокси-модуля средств M2M SC при осуществлении связи с сетью M2M SP, которая также разворачивает сервер средств M2M SC.

(II) Предоставление гостевой сети AN, которая разворачивает средства M2M SC в своей сети, возможности направлять M2M услуги непосредственно в сеть M2M SP (которая может быть домашней сетью M2M SP или гостевой сетью M2M SP). Это основано на политики домашней сотовой сети AN, которая может отражать особенности подписки на M2M транспортировку. Это также может быть основано на политики сети M2M SP и/или подписке на M2M услуги.

(III) Предоставление оператору сотовой сети AN возможности предлагать M2M услуги поставщикам M2M услуг, которые разворачивают архитектуру уровня M2M услуг (М2М SL), которая отличается от архитектуры ETSI SL, путем определения необходимой функции взаимодействия (IWKF).

(IV) Предоставление поставщику услуг сотовой сети AN возможности предлагать транспортные и другие услуги любой сети M2M SP независимо от архитектуры сети поставщика (SP) в соответствии с M2M SC; то есть независимо от того, развернуты ли средства M2M SC в сети поставщика услуг (SP), или нет.

(V) Разрешение поставщику услуг сотовой сети AN предоставлять транспортные и другие услуги любой сети M2M SP независимо от того, имеет ли оператор сотовой сети AN существующее соглашение (SLA) с поставщиком услуг (SP) или нет.

Конкретные варианты настоящего изобретения кроме того обеспечивают техническое решение по активации M2M услуг (MSES), которое показывает, как использовать вышеупомянутую общую архитектуру активации M2M услуг в контексте сети доступа 3GPP. Это решение позволяет сети AN 3GPP предлагать транспортное соединение для M2M устройств через развитое пакетное ядро (EPC) 3GPP для поставщика M2M услуг, выбранного M2M устройством. Техническое решение, предложенное в настоящем изобретении для активации M2M услуг, не изменяет существующие процедуры сети доступа для установления транспортного соединения через сеть AN с использованием радиоинтерфейса. Другими словами, за исключением небольших усовершенствований установка соединения на транспортном уровне может продолжаться с использованием процедур, которые определены стандартами сетей AN. Вдобавок, техническое решение согласно настоящему изобретению также обеспечивает динамический механизм, который разрешает конфигурацию межуровневого идентификатора M2M устройства/шлюза, когда сеть AN 3GPP, поставщик M2M услуг (M2M SP) и M2M устройство полностью осведомлены об упомянутом межуровневом идентификаторе M2M устройства/шлюза. Таким образом, в конкретных вариантах настоящего изобретения предлагается общее техническое решение для активации M2M услуг для любого M2M устройства, которое применяет любой сотовый доступ, используемый ядром 3GPP EPC для обеспечения транспортного соединения.

В одном варианте настоящего изобретения обеспечен способ использования развитого пакетного ядра (EPC) Проекта партнерства 3-го поколения (3GPP) на основе беспроводной сети доступа (AN) для активации подключения объекта межмашинной связи к сети поставщика M2M услуг (SP), выбранной M2M объектом. Способ содержит выполнение следующих этапов с использованием сети AN: (i) прием начального запроса от M2M объекта на подключение к сети M2M SP, причем начальный запрос содержит идентификатор подписки на M2M доступ, характерный для объекта; (ii) получение имени точки доступа (APN) для приложения используемых по умолчанию сетевых служебных средств (N-SC) M2M на основе AN с использованием идентификатора подписки на M2M доступ независимо от любого другого APN, полученного от M2M объекта в качестве части начального запроса; (iii) соединение M2M объекта с приложением используемых по умолчанию средств M2M N-SC c использованием APN приложения используемых по умолчанию средств M2M N-SC на базе сети AN; и (iv) обеспечение начальной регистрации M2M объекта на уровне услуг (SL) M2M в сети M2M SP с использованием используемого по умолчанию приложения M2M N-SC на основе AN.

В другом варианте настоящее изобретение имеет своей целью создание беспроводной сети AN на основе EPC 3GPP для активации подключения M2M объекта к сети средств M2M SP, выбранной M2M объектом. Сеть AN сконфигурирована для выполнения следующего: (i) приема начального запроса от M2M объекта на подключение к сети M2M SP, причем начальный запрос содержит идентификатор подписки на M2M доступ, характерный для объекта; (ii) получения APN приложения используемых по умолчанию средств M2M N-SC на основе AN с использованием идентификатора подписки на M2M доступ независимо от любого другого APN, полученного от M2M объекта в качестве части начального запроса; (iii) соединения M2M объекта с приложением используемых по умолчанию услуг M2M N-SC c использованием APN используемого по умолчанию приложения M2M N-SC на базе сети AN; и (iv) обеспечения начальной регистрации M2M объекта на уровне M2M SL в сети M2M SP с использованием приложения используемых по умолчанию средств M2M N-SC на основе AN.

В дополнительном варианте настоящее изобретение имеет своей целью создание M2M объекта, сконфигурированного для осуществления связи с сетью M2M SP через беспроводную сеть AN на основе EPC 3GPP. M2M объект содержит память и процессор, соединенный с памятью. Память сконфигурирована для запоминания идентификатора подписки на M2M доступ для M2M объекта. Процессор сконфигурирован для выполнения следующего: (i) посылки начального запроса в сеть AN для подключения к сети M2M SP, причем начальный запрос содержит идентификатор подписки на M2M доступ; (ii) соединения с приложением используемых по умолчанию средств M2M N-SC на основе AN с использованием его APN независимо от любого другого APN, посланного процессором в сеть AN в качестве части начального запроса; и (iii) выполнения начальной регистрации M2M объекта на уровне M2M SL в сети M2M SP с использованием приложения используемых по умолчанию средств M2M N-SC на основе AN.

В еще одном варианте настоящее изобретение имеет своей целью улучшение способа использования сотовой сети AN для подключения M2M объекта к сети M2M SP, выбранной M2M объектом. Упомянутое улучшение содержит: прием сетью AN начального запроса от M2M объекта на подключение к сети M2M SP; соединение через сеть AN M2M объекта с приложением используемых по умолчанию средств M2M N-SC на основе AN с использованием APN приложения используемых по умолчанию средств M2M N-SC на основе AN независимо от любого другого APN, полученного от M2M объекта в качестве части начального запроса; и обеспечение сетью AN регистрации M2M объекта на уровне M2M SL в сети M2M SP с использованием приложения используемых по умолчанию средств M2M N-SC на основе AN.

Общая архитектура для активации M2M услуг (которая соответствует архитектуре ETSI M2M SL), предложенная в конкретных вариантах настоящего изобретения предоставляет свободный выбор поставщика M2M SP в соответствии с динамикой рынка и одновременно допускает возможность реализации слабо связанной архитектуры M2M услуг. Таким образом, архитектура для активации M2M услуг согласно некоторым вариантам настоящего изобретения обеспечивает гибкость и предоставляет оператору сотовой сети AN возможность предоставления услуг сети доступа, включая транспортные уровни, для их использования при реализации M2M услуг в соответствии с архитектурой ETSI M2M SL таким путем, который позволяет оператору сотовой сети AN добиться следующего: (а) использовать единую модель разворачивания для разворачивания приложения для активации средств M2M SC в своей сети при сохранении возможности обслуживания всех типов операторов M2M услуг; (b) иметь немедленный и легкий доступ к любой информации, необходимой для реализации межуровневых функциональных возможностей. Эту информацию можно использовать в помощь оператору сотовой сети AN, когда оператор предлагает свою сеть AN в виде более интеллектуального канала (так называемый «битпайп»); (с) обслуживать других поставщиков M2M услуг, которые используют архитектуру, не являющуюся архитектурой ETSI M2M SL; (d) обладать гибкостью для маршрутизации M2M трафика в гостевой сети на основе политики оператора (домашней) сотовой сети AN и M2M подписки.

Общая архитектура для активации M2M услуг согласно конкретным вариантам настоящего изобретения также позволяет поставщику M2M услуг (M2M SP): (а) разворачивать приложение средств M2M SC в своей сети без необходимости поддержки взаимодействующих интерфейсов разных сотовых сетей AN. Это можно сделать, если обеспечить реализацию функциональных возможностей прокси-модуля средств M2M SC внутри сотой сети AN; (b) разворачивать свои услуги с использованием одновременно множества технологий доступа, но одной и той же модели разворачивания.

В приведенной в качестве примера сети доступа 3GPP некоторые варианты настоящего изобретения: (а) дают возможность оператору сети AN 3GPP предоставлять свои транспортные услуги любому M2M устройству, которое для соединения с выбранным поставщиком M2M SP использует EPC 3GPP, когда сеть AN 3GPP полностью осведомлена о межуровневом идентификаторе M2M устройства/шлюза, типе трафика, используемого через транспортное соединение, и M2M приложениях, которые используют созданное транспортное соединение; (b) дают возможность поставщику M2M SP предлагать начальную активацию услуг своим M2M устройствам, которые используют любой тип сотового доступа (например, развитая высокоскоростная передача пакетных данных (eHRPD) на основе 3GPP, E-UTRAN, CDMA2000 и т.д.), и динамически конфигурировать межуровневый идентификатор M2M устройства для каждого выбранного M2M SP, и в то же время предоставляет возможность связаться с M2M устройством, как только оно зарегистрировано; (с) обеспечивают динамическое решение для обновления подписки на M2M доступ (для M2M устройства/шлюза) с динамически распределенным межуровневым идентификатором M2M устройства/шлюза и обновленными именами точек доступа (APN) для сетевых служебных средств M2M (например, сигнализация и имена APN для данных на уровне услуг (SL); (d) обеспечивают динамическое решение для обновления профиля политики абонента, осуществляющего M2M доступ, с помощью функции, контролирующей выполнение правил работы в сети и учета стоимости (PCRF), с использованием динамически распределенного межуровневого идентификатора M2M устройства и M2M приложений и связанных с ними показателей QoS.

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

В последующем разделе представлено описание настоящего изобретения со ссылками на существующие варианты его осуществления, проиллюстрированные чертежами, на которых:

Фиг. 1 - существующая архитектура для активации M2M услуг с использованием сотовой сети доступа;

фиг.2 - логическая блок-схема приведенного в качестве примера объекта M2M связи, который может приводиться в действие из домена M2M устройств;

фиг. 3 - универсальная архитектура для активации M2M услуг (для сотовых сетей) согласно одному варианту настоящего изобретения, где показаны две разные архитектурные опции, позволяющие разворачивать средства M2M SC отдельно от сервера M2M AS;

фиг. 4 - приведенная в качестве примера архитектура для активации M2M услуг с использованием прокси-модуля средств M2M SC в сотовой сети AN согласно одному варианту настоящего изобретения;

фиг. 5 - приведенная в качестве примера блок-схема, относящаяся к разворачиванию прокси-модуля средств M2M SC в сотовой сети AN согласно одному варианту настоящего изобретения;

фиг. 6 - приведенная в качестве примера блок-схема прокси-модуля средств M2M SC согласно одному варианту настоящего изобретения;

фиг. 7 - общий вид вариантов архитектуры, обеспечивающих активацию M2M услуг для сотовой сети AN;

фиг. 8А - приведенная в качестве примера архитектура для активации M2M услуг (не являющаяся архитектурой ETSI) для сотовой сети AN, относящаяся к варианту 3.1 на фиг. 7;

фиг. 8В - приведенная в качестве примера архитектура для активации M2M услуг (не являющаяся архитектурой ETSI) для сотовой сети AN, относящаяся к варианту 3.2 на фиг. 7;

фиг. 9 - блок-схема приведенного в качестве примера объекта M2M связи согласно одному варианту настоящего изобретения;

фиг. 10 - приведенная в качестве примера блок-схема, дающая общее представление о том, каким образом M2M объект подключается к сети каждого выбранного поставщика M2M SP в техническом решении, касающемся активации M2M услуг в стандарте 3GPP согласно одному варианту настоящего изобретения;

фиг. 11 - приведенная в качестве примера сетевая архитектура, где показано использование используемых по умолчанию средств M2M N-SC во время начального подключения M2M объекта к сети SP согласно одному варианту технического решения, касающегося активации M2M услуг для доступов 3GPP;

фиг. 12 - приведенная в качестве примера сетевая архитектура, где показано использование постоянных средств M2M N-SC на основе AN во время постоянного подключения M2M объекта к сети M2M SP согласно одному варианту технического решения, касающегося M2M услуг 3GPP согласно базовым принципам настоящего изобретения;

фиг. 13 - общее представление приведенных в качестве примера вариантов архитектуры, которые относятся к активации M2M услуг для сети AN 3GPP;

фиг. 14 - приведенные в качестве примера последовательности операций по обработке вызова высокого уровня согласно одному варианту настоящего изобретения при начальном подключении M2M объекта к выбранному поставщику M2M SP через сеть AN 3GPP;

фиг. 15 - приведенные в качестве примера последовательности операций по обработке вызова высокого уровня согласно одному варианту настоящего изобретения при постоянном подключении M2M объекта к выбранному поставщику M2M SP через сеть AN 3GPP; и

фиг. 16 - другие приведенные в качестве примера последовательности операций согласно одному варианту настоящего изобретения при постоянном подключении M2M объекта к выбранному поставщику M2M SP через сеть AN 3GPP.

ПОДРОБНОЕ ОПИСАНИЕ

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

Встречающиеся во всем этом описании ссылки на «один вариант» означают, что конкретный признак, структура или характеристика, описанная в связи с данным вариантом, включена по меньшей мере в один вариант настоящего изобретения. Таким образом, словосочетания «в одном варианте» или «согласно одному варианту» (или другие словосочетания, имеющие аналогичное значение) в различных местах ко всему описанию не обязательно относятся к одному и тому же варианту. Кроме того, конкретные признаки, структура или характеристики могут быть скомбинированы любым подходящим образом в одном или нескольких вариантах. Также в зависимости от контекста обсуждения форма единственного числа может включать в себя формы множественного числа, а форма множественного числа может включать форму единственно числа. Аналогичным образом соединенный черточкой термин (например, «внутри-полосный», «меж-уровневый» и т.д. и его версия без черточки (например «внутриполосный», «межуровневый» и т.д.) могут использоваться как взаимозаменяемые; запись с прописными буквами (например, «Прокси-модуль», «Архитектура Активации Услуг», «Сеть Доступа», «Межуровневый» и т.д.) и запись со строчными буквами (например, «прокси-модуль», «архитектура активации услуг», «сеть доступа», «межуровневый» и т.д.) могут использоваться как взаимозаменяемые. Указанные происходящие случаи взаимозаменяемости не следует рассматривать как несовместимые.

Заметим прежде всего, что термины «связанный» «соединенный», «соединяющий», «электрически соединенный» и т.д., используются здесь как взаимозаменяемые для общей характеристики состояния, характеризующегося наличием электрического/электронного соединения. Аналогичным образом, здесь считается, что первый объект находится «на связи» со вторым объектом (или объектами), когда первый объект электрическим путем посылает и/или принимает (будь то с помощью проводных либо беспроводных средств) информационные сигналы (будь то сигналы, содержащие речевую информацию, либо содержащие неречевые данные/управляющую информацию) на/от второго объекта независимо от типа (аналоговый или цифровой) этих сигналов. Кроме того, заметим, что показанные здесь и обсуждаемые различные чертежи (включая компонентные схемы) носят исключительно иллюстративный характер и представлены без соблюдения масштаба.

ЧАСТЬ 1

На фиг. 3 представлена универсальная архитектура 60 для активации M2M услуг (для сотовой сети) согласно одному варианту настоящего изобретения, где показаны две разные возможные архитектурные опции, позволяющие развернуть приложение 42 для активации средств M2M SC отдельно от сервера M2M AS 62. Из приведенного выше обсуждения очевидно, что такое раздельное разворачивание позволяет обеспечить соответствие архитектуры 60 требованиям, разработанным ETSI M2M TC для архитектуры M2M SL, которая должна соответствовать стандарту ETSI TS 102.69. Что касается приведенного ниже описания, то фигуры 3-8 относятся к Части 1 настоящего изобретения (в которой обсуждается универсальная архитектура для активации M2M услуг для сотовых сетей доступа), в то время как фигуры 9-16 относятся к Части 2 настоящего изобретения (где предложены примеры сигнализации и другие подробности реализации архитектуры для активации M2M услуг, описанной в Части 1 в контексте сети доступа 3GPP). Однако разделение обсуждения на указанные разные части сделано исключительно для удобства, и указанное разделение не следует трактовать как отсутствие непрерывности или связности этих двух частей обсуждения. Заметим здесь, что из-за наличия разных сетевых конфигураций, возможных в разных вариантах настоящего изобретения, разные сетевые элементы (в сотовой сети AN и сети поставщика услуг (SP)), общие для фигур 1 и 3 и имеющие обычно подобные функциональные возможности, все же обозначены разными ссылочными позициями на фиг. 3, чтобы отличать их в том смысле, что они реализованы в архитектуре 60, а также чтобы подчеркнуть то обстоятельство, что сетевые элементы, указанные на фиг. 3, можно соответствующим образом сконфигурировать или модифицировать (аппаратными средствами, программными средствами или и теми и другими) (в отличие от их аналогов на фиг. 1), для реализации разных функциональных возможностей (более подробно обсуждаемых ниже) согласно конкретным вариантам настоящего изобретения. Таким образом, на фиг. 3 такими же ссылочными позициями, как на фиг. 1, отмечены только домен 34 M2M устройств, линии 23А-23С радиосвязи, средства M2M SC 42 и M2M пользовательское устройство 44. Однако «внутренние сетевые элементы сотовой транспортной сети 64 (то есть той части сотовой сети AN, которая обеспечивает поддержку транспортного уровня для M2M передач от M2M устройств/шлюзов в домене 34 M2M устройств), такие как сотовые участки 66-68, базовые станции (BS) 70-72 и M2M ядро 74, содержащее сотовую транзитную часть 76, базовую сеть 78 и функцию 80 взаимодействия (IWKF) (обсуждаемую ниже), обеспечены ссылочными позициями, отличными от тех, которые используются для идентификации элементов, имеющих функциональные возможности, подобные фиг. 1. Аналогичным образом, сервер M2M AS 62 в варианте на фиг. 3 может представлять собой модифицированную версию M2M AS 46 на фиг. 1, чтобы дать возможность реализации в архитектуре 60 по фиг. 3. Таким образом, для сервера M2M AS 62 на фиг. 3 предусмотрена другая ссылочная позиция, чтобы отличить его от M2M AS 46 на фиг. 1, даже в том случае, если они оба могут иметь по существу одинаковые функциональные возможности. Заметим здесь, что хотя различные объекты M2M связи (типа объектов 24-32 на фиг. 1) ради упрощения чертежей не показаны как часть домена 34 M2M устройства на фиг. 3, их присутствие на фиг. 3 (и на аналогичных фигурах, обсуждаемых ниже) подразумевается.

Как показано на фиг. 3, двумя разными опциями (основанными на разворачивании общих средств M2M SC 42) могут быть: (а) Опция 1: тесно связанная архитектура M2M услуг (в которой средства M2M SC 42 находятся внутри сети SP, идентифицированной ссылочной позицией «82» и показанной пунктирной линией на фиг. 3). Эта опция называется «Опция 1» (смотри первую сетевую конфигурацию или NT1) в нижней части фиг. 3; (b) Опция 2: слабо связанная или распределенная архитектура M2M услуг (в которой средства M2M SC 42 находится внутри сотовой сети AN, идентифицированной ссылочной позицией «84» и также показанной на фиг. 3 пунктирной линией). Эта опция показана как «Опция 2» (смотри вторую сетевую конфигурацию или NT2) в нижней части фиг. 3. На фиг. 3 сеть SP 82 и сотовая сеть AN 84 показаны разными пунктирными линиями, чтобы указать, что эти гибкие архитектурные опции получились из вышеописанных двух вариантов разворачивания для общих средств M2M SC 42. Очевидно, что реализация этих двух опций разворачивания приводит к двум разным сотовым сетям 84 доступа (с M2M SC 42) и 86 (без M2M SC 42) и двум разным сетям M2M SP 82 (с M2M SC 42) и 88 (без M2M SC 42). Перед подробным обсуждением дополнительных аспектов архитектуры 60 и других комбинаций указанной сети доступа и конфигураций сети SP, далее следует краткий обзор некоторых сетевых элементов на фиг. 3.

Для краткости каждый сетевой элемент или другой объект на фиг. 3 подробно не описывается, особенно если иметь в виду ранее проведенное подробное обсуждение аналогичных элементов/объектов на фиг. 1 (которое продолжается применительно также и к контексту фиг. 3). Однако, в некоторых элементах на фиг. 3 предусмотрено несколько дополнительных деталей. Например, каждая из базовых станций или узлов 70-72 доступа может представлять собой базовую станцию (BS) в сети 3G (третьего поколения) или развитый узел B (eNodeB) или домашний eNodeB (HeNB), когда транспортная сеть 64 является сетью стандарта LTE (Проект долгосрочного развития). В других вариантах одна или несколько BS 70-72 могут также включать в себя контроллер участка, точку доступа (AP), радиомачту или устройство-интерфейс радиосвязи любого другого типа, способное функционировать в беспроводной среде. В одном варианте одна или несколько базовых станций 70-72 могут быть сконфигурированы для реализации компоновки для внутрисотовой или межсотовой скоординированной многоточечной передачи /приема (CoMP). В случае сети оператора LTE базовая сеть 78 может представлять собой шлюз доступа (AGW). Понятно, что сотовая сеть AN 84 или 86 (в зависимости от вышеупомянутой конкретной конфигурации) может представлять собой сотовую телефонную сеть или наземную сеть мобильной связи общего пользования (PLMN), в которой M2M устройства 24-32 (показанные на фиг. 1, но не показанные для упрощения чертежа на фиг. 3) могут представлять собой абонентские блоки. Кроме того, участки сотовой сети AN 84 или 86 могут включать в себя (независимо или в комбинации) любую из существующих или будущих проводных или беспроводных сетей связи, таких как, например, PSTN, сеть на основе подсистемы IP мультимедиа (IMS), или любую линию связи на основе спутников. В некоторых вариантах сеть AN 84 или 86 может быть подсоединена к сети Интернет через соединение своей базовой сети 78 с IP сетью с пакетной коммутацией (не показана), или может включать в себя часть сети Интернет в качестве составной части. В одном варианте сотовая сеть AN может включать в себя большее или меньшее количество функциональных объектов или функциональные объекты другого типа, чем те, которые показаны на фиг. 3 в контексте сотовой сети AN 84 или 86.

Хотя различные примеры, использованные в приведенном ниже обсуждении, представлены в основном в контексте сотовой сети AN 84 (или 86), являющейся сетью доступа 3GPP, основополагающие принципы настоящего изобретения можно равным образом применить с подходящими модификациями (как очевидно специалистам в данной области техники, использующим эти принципы) к ряду других систем или сетей, а именно, на основе мультиплексирования с частотным разделением каналов (FDM) и мультиплексирования с временным разделением каналов (TDM) (а также для беспроводных дуплексных систем/сетей с частотным разделением каналов (FDD) и с временным разделением каналов (TDD)). Указанные сотовые сети и системы могут включать в себя, например, стандартизированные системы/сети, где используются спецификации 2G (Второго поколения), 3G (Третьего поколения) или 4G (Четвертого поколения) или нестандартизированные системы. Некоторые примеры указанных систем или сетей включают в себя, но не только: сети GSM, сети GPRS, системы TDMA на основе промежуточного стандарта (IS-136) Ассоциации промышленности средств связи/Ассоциации изготовителей электронного оборудования (TIA/EIA), системы широкополосного множественного доступа с кодовым разделением каналов (WCDMA), сети 3GPP LTE, системы высокоскоростного пакетного доступа (HSPA) на основе WCDMA, системы высокоскоростной передачи пакетных данных (HRPD) или eHRPD на основе CDMA 3GPP2 системы CDMA2000 или TIA/EIA IS-2000, системы EV-DO, системы WiMAX, системы усовершенствованной международной мобильной электросвязи (IMT-Advanced) (например, системы LTE Advanced), другие сети UTRAN или E-UTRAN, системы GSM/EDGE, сети доступа на основе Протокола форума ограниченного доступа или на основе другого IP, не стандартизированную беспроводную частную корпоративную сеть и т.д.

Вновь обратимся к фиг. 3, где функция IWKF 80 (которая в некоторых литературных источниках также встречается под называнием «MTC IWKF» или «MTC IWF) может быть реализована в сотовой сети AN 84 (или 86), причем один или несколько экземпляров указанной MTC IWKF могут находиться в сотовой сети AN 84 или 86 (которая может представлять собой, например, домашнюю сеть PLMN (HPLMN) для одного или нескольких M2M устройств в домене 34 M2M устройств). Функция IWKF 80 может представлять собой автономный объект или быть функциональным объектом другого сетевого элемента (например, прокси-модуля 100 средств MDM SC, который обсуждается ниже со ссылками на фиг. 4). Функция IWKF 80 может обеспечить интерфейс и функционировать в качестве промежуточного объекта для способствования связи между сотовой сетью CN 78 и сервером M2M SC (который в некоторых литературных источниках называется «MTC сервер») (например, сервер 102 M2M SC, показанный на фиг. 4, который обсуждается ниже). Функция IWKF 80 может быть использована для связи в плоскости управления для скрытия внутренней топологии сотовой сети AN 84 (или 86), либо для ретрансляции и преобразования протоколов сигнализации, используемых для M2M связи (для активации конкретных функциональных возможностей в сети AN 84 или 86). В одном варианте функция IWKF 80 может аутентифицировать сервер средств M2M SC перед установлением связи с сотовой сетью AN 84 или 86, может авторизовать запросы плоскости управления от сервера средств M2M SC и/или может поддерживать защищенные передачи между сотовой сетью AN 84 (или 86) и сервером средств M2M SC. На фиг. 3 двунаправленная пунктирная линия 90 указывает возможный вариант сигнализации в плоскости пользователя между объектом сети AN (здесь это CN 78) и объектом поставщика услуг (SP) (здесь это AS 62). Другие сплошные двунаправленные линии (которые для краткости отдельно не идентифицированы на фиг. 3) указывают «типовую» сигнализацию (и межсоединения) в плоскости пользователя, охватывающую различные объекты в сотовой сети AN 84 (или 86), а также сети 82 (или 88) поставщика SP.

Раздел I: Использование прокси-модуля средств M2M SC в сети доступа

Использование средств M2M SC 42 в сотовой сети AN обеспечивает точку ввода для поставщика услуг сотовой сети AN ко всей информации, которая необходима для активации межуровневых функциональных возможностей. Другими словами, такое использование позволяет оператору сотовой сети доступа обращаться к необходимой информации, касающейся межуровневого идентификатора M2M устройства/шлюза, возможного идентификатора M2M D/G-SC и M2M приложений, которые выполняются на устройстве M2M услуг (например, устройство 58, показанное на фиг. 2), использующем устройство M2M транспортировки (например, устройство 56 доступа/транспортировки на фиг. 2) через радиоинтерфейс сотовой сети доступа и уровень доступа/транспортный уровень. Эта опция может качественно работать, когда средства M2M SC 42 развернуты внутри сотовой сети оператора в качестве сервера средств M2M SC (не показан), когда сеть поставщика услуг не имеет развернутых средств M2M SC.

Однако, когда сотовая сеть AN не разворачивает сервер средств M2M SC, а сеть поставщика SP разворачивает общие средства M2M SC 42 в виде сервера средств M2M SC (например, сервер 102 средств M2M SC, показанный на фиг. 4 и обсуждаемый ниже), возможно потребуется предоставить функциональные возможности прокси-модуля M2M SC (например, прокси-модуля 100 средств M2M SC, показанного на фиг. 4 и обсуждаемого ниже) в сотовой сети AN, чтобы дать возможность оператору сотовой сети доступа обращаться к межуровневой информации, которая необходима для активации M2M услуг.

На фиг. 4 показана приведенная в качестве примера архитектура 95 для активации M2M услуг, использующая прокси-модуль 100 средств M2M SC (боле подробно показанного на фиг. 6) в сотовой сети AN согласно варианту настоящего изобретения. Архитектура 95 иллюстрирует ситуацию, в которой каждая сеть (сотовая сеть AN и сеть поставщика SP) разворачивает общие средства M2M SC 42, показанные двумя перекрывающимися (обведенными пунктиром) сетевыми конфигурациями 82 (сеть 1 или NT1 под опцией 1, упомянутой выше) и 84 (сеть 2 или NT2 под опцией 2, упомянутой выше) на фиг. 3. Для краткости изложения обсуждение сетевых элементов или других объектов, имеющих одинаковые функциональные возможности, являющиеся общими на фигурах 3 и 4 (где они обозначены одинаковыми ссылочными позициями), здесь не повторяется. Также для краткости изложения сотовая сеть AN 84 (на фиг. 3) обозначена как взаимозаменяемая в виде транспортной сети 84 на фиг. 4, чтобы указать на наличие поддержки уровня доступа/транспортного уровня в сети 84. Транспортная сеть 84 включает в себя модифицированное M2M ядро 97 (в противоположность M2M ядру 74 на фиг. 3, которое содержит прокси-модуль 100 функций M2M SC. Сеть 82 поставщика SP включает в себя аналогичный сервер 102 функций M2M SC (который представляет собой развернутую версию домашних средств M2M SC поставщика услуг (SP)). Термины «сервер средств M2M SC», «M2M сервер» или «MTC сервер» могут использоваться в качестве взаимозаменяемых в некоторых литературных источниках. Однако для непротиворечивости изложения в приведенном ниже обсуждении используются только термины «сервер средств M2M SC» или «M2M сервер». Сервер 102 средств M2M SC может быть соединен с сотовой сетью AN 84 (например, через прокси-модуль 100 средств M2M SC в варианте на фиг. 4). Для осуществления связи с M2M устройствами/шлюзами (работающими в домене 34 M2M устройств), которые используются для MTC. В одном варианте сервер 102 средств SC и M2M пользователь 44 могут быть либо отдельными объектами, либо совмещенными объектами. Прокси-модуль 100 средств M2M SC и сервер 102 средств M2M SC могут взаимодействовать друг с другом, используя подходящий интерфейс API, как здесь показано. Аналогичным образом, сервер 102 средств M2M SC и сервер 62 M2M доступа также могут взаимодействовать друг с другом, используя подходящий API, как показано на фиг. 4. Между сотовой сетью CN 78 и сервером 62 M2M доступа в некоторых вариантах настоящего изобретения также с помощью двунаправленной линии 90, соединяющей эти два объекта, также показана опционная сигнализация в плоскости пользователя.

Следует заметить, что в текущих версиях ETSI TS 102.69 и Технического отчета (TR) 23. 888 Проекта 3GPP (озаглавленного «Системные усовершенствования для машинной связи») не обсуждается указанное совместное развертывание общих средств M2M SC 42 и связанной с ними сигнализации, а также архитектурные детали, в результате чего получается, что некоторые опции развертывания взаимодействия (между сотовой сетью AN и сетью SP) не имеют своего адресата. Вариант, показанный на фиг. 4, относится к этой ситуации, хотя он соответствует принципам, разработанным Комитетом ETSI M2M TC и касающихся архитектуры уровня M2M SL, независимой от типа доступа, которые упоминались ранее в разделе «Уровень техники» настоящего описания. Таким образом, в архитектуре 95 по фиг. 4 средства M2M SC сотовой сети доступа (то есть общие средств M2M SC 42, развернутые в сотовой сети AN) действуют в качестве прокси-модуля 100 средств M2M SC, который сконфигурирован для ретрансляции всех передач в плоскости сигнализации между средствами D/G-SC (находящимися в соответствующих M2M устройствах или шлюзах, работающих в домене 24 M2M устройств, как упоминалось ранее) и сервером 102 средств M2M SC поставщика услуг. Не только для вышеуказанного, но прокси-модуль 100 M2M SC также может быть сконфигурирован для предоставления оператору сотовой сети доступа ко всей межуровневой информации, которая необходима для активации M2M услуг в сотовой сети доступа. Использование прокси-модуля средств M2M SC может дать множество дополнительных функциональных возможностей, некоторые примеры которых приведены ниже.

(1) Действие в качестве прокси-модуля от лица сервера средств M2M SC поставщика M2M услуг. Заметим здесь, что, когда в качестве сервера средств M2M SC развернуты общие средства M2M SC 42 (независимо от того, имеет ли это место в сети SP или сети AN (как это более подробно обсуждается ниже)) средства D/G-SC используют этот сервер M2M SC для регистрации M2M услуг. Таким образом, здесь функции прокси-модуля 100 средств M2M SC выполняются средствами M2M SC, которые действуют в качестве прокси-модуля для другого сервера M2M SC (здесь это сервер 102 M2M SC в сети 82 поставщика M2M услуг). Такой подход позволяет оператору сотовой сети AN не только развернуть свои M2M SC в виде сервера M2M SC в своей сетевой области, но также использовать свои M2M SC для работы в качестве прокси-модуля M2M SC при осуществлении связи с сетью M2M SP, в которой также развернут сервер M2M SC.

(2) Если в качестве прокси-модуля M2M SC действуют средства M2M SC сотовой сети доступа, то поставщику M2M услуг нет необходимости непосредственно взаимодействовать с базовой сотовой сетью для реализации дополнительных услуг (например, распределение IP адресов, нахождение M2M устройств/шлюзов (то есть идентификация о нахождении конкретного объекта M2M связи) и т.д.), предлагаемых сотовой сетью доступа. Это позволяет разместить интерфейс IWKF 80 в прокси-модуле 100 средств M2M SC сотовой сети доступа (как показано на фиг. 4), что обеспечивает эффективность описываемой архитектуры. В общем случае при использовании конфигурации прокси-сервера по фиг. 4 появляются две возможности взаимодействия: (а) функциональные возможности взаимодействия уже реализованы в сервере 102 средств M2M SC, и тогда с точки зрения сервера 102 средств M2M SC неважно, как развернут интерфейс 80 IWKF в сети AN 84; (b) функциональные возможности взаимодействия в сервере 102 M2M SC не реализованы, и тогда прокси-модуль 100 средств M2M SC может обеспечить необходимое взаимодействие посредством совместно расположенного IWKF 80. Таким образом, в любом случае серверу 102 средств M2M SC на основе SP нет необходимости поддерживать функцию 80 (IWK). В любом случае в одном варианте, если прокси-модуль 100 средств M2M SC активирован и поддерживается, то поставщик M2M SP 82 всегда может связаться с сетью AN 84 через тот же самый интерфейс; то есть когда SP имеет собственный сервер 102 средств M2M SC, этот сервер может осуществлять связь с другим сервером (здесь это прокси-модуль 100 средств M2M SC) стандартным образом, и у него нет необходимости знать о существовании интерфейса IWKF или знать, каким образом реализован указанный интерфейс в сети доступа. Однако очевидно, что IWKF 80 может быть реализован отдельно от прокси-модуля 100 средств M2M SC (например, между сетью CN и прокси-модулем средств M2M SC, как это показано на фиг. 3) в некоторых вариантах изобретения, и следовательно, он не обязательно должен находиться в прокси-модуле 100 средств M2M SC в этих вариантах осуществления изобретения.

(3) Наличие доступа к сигнализации между D/G-SC и сервером 102 средств M2M SC сети поставщика M2M услуг. Это позволяет исключить дополнительную сигнализацию и обеспечить необходимую оптимизацию, которая может потребоваться в том случае, когда сервер средств M2M SC находится у поставщика M2M услуг, и требуется какая-либо из услуг сотовой сети доступа. Например, в случае использования специального ID устройства между M2M SP и сотовой сети может понадобиться соглашение об этом специальном ID устройства (например, об межуровневом идентификаторе M2M устройства, упомянутом выше), который будет использован между SP и поставщиком услуг сети AN. В этом случае наличие интерфейса (например, интерфейса на основе API, показанного на фиг. 4) между сервером 102 M2M услуг и прокси-модулем 100 может дать сотовой сети AN возможность получить указанную информацию (здесь это специальный ID устройства) по сети SP через этот интерфейс. В противном случае, для передачи этой информации между указанными двумя объектами должна быть использована какая-то другая сигнализация или процедура.

На фиг. 5 показана приведенная в качестве примера блок-схема 105, относящаяся к развертыванию прокси-модуля средств M2M SC (например, прокси-модуля 100 M2M SC на фиг. 4) в сотовой сети AN (например, сотовой сети AN 84 на фиг. 4) согласно одному варианту настоящего изобретения. Блок-схема 105 на фиг. 5 относится к способу обеспечения M2M связи с использованием сотовой сети AN 84, которая оперативно подсоединена к сети поставщика M2M услуг (например, SP 82 M2M услуг на фиг. 4). Как показано в блоке 107 и упоминалось ранее со ссылками на фиг. 4, оператор сотовой сети AN может развернуть часть общих средств M2M SC 42 (на фиг. 3) внутри своей сотовой сети AN. Затем (блок 108) оператор сети AN может сконфигурировать развернутые средства M2M SC для функционирования в виде прокси-модуля 100 средств M2M SC, когда M2M SP 82 разворачивает часть общих функций M2M SC 42 в виде сервера 102 M2M SC (и когда отсутствует сервер M2M SC, развернутый в сотовой сети AN 84). Кроме того (смотри блок 109) оператор сотовой сети AN может сконфигурировать прокси-модуль 100 M2M SC для его функционирования от лица соответствующего сервера 102 средств M2M SC в сети 82 M2M SP, и для ретрансляции сообщений в плоскости сигнализации между средствами SC, характерными для объекта, в объекте M2M связи (действующем в домене 34 M2M устройств) (например, M2M устройство или M2M шлюз, показанные на фиг. 1, но не показанные на других фигурах для упрощения иллюстраций) и сервером 102 средств M2M SC. Как упоминалось ранее, оператор сети AN также может (но не обязательно) поместить IWKF 80 в прокси-модуль 100 средств M2M SC, как показано с помощью точечного блока 110 на фиг. 5. Таким образом, архитектура для активации M2M услуг, использующая прокси-модуль средств M2M SC в сотовой сети доступа (например, архитектура 95 на фиг. 4), может быть выполнена в соответствии с ранее обсужденными требованиями, предъявляемыми к архитектуре ETSI M2M SL.

На фиг. 6 в качестве примера представлена блок-схема прокси-модуля средств M2M SC (например, прокси-модуля 100, показанного на фиг. 4) согласно одному варианту настоящего изобретения. В одном варианте прокси-модуль 100 средств M2M SC может представлять собой блок для обработки или вычисления данных (например, компьютер или персональный компьютер общего назначения, рабочая станция и т.д.), который соответствующим образом сконфигурирован (в виде аппаратных и/или программных средств) для выполнения различных обсужденных здесь функциональных возможностей прокси-модуля. В этой связи, прокси-модуль 100 может включать в себя блок обработки и управления (PCU) 112, который может выполнять приложение, связанное с прокси-модулем (программный код), для предоставления прокси-модулю 100 возможности обеспечить необходимые функциональные возможности прокси-модуля (с использованием, например, модуля управления технологическим процессом Java^TM) согласно основополагающим принципам различных вариантов настоящего изобретения. Прокси-модуль 100 средств M2M SC может также содержать считываемый компьютером носитель данных (показанный и названный здесь «памятью» 114 на фиг. 6) электрически соединенную с PCU 112. Память 114 может содержать программный код (не показан), который при его исполнении блоком PCU 112 может сконфигурировать прокси-модуль 100 для обеспечения обсужденных здесь различных функциональных возможностей, относящихся к прокси-модулю. Таким образом, в приведенном здесь обсуждении, хотя прокси-модуль 100 средств M2M SC (или любой другой элемент или объект, показанный на фигурах 3-4 или на других аналогичных фигурах, обсуждаемых ниже) может называться «выполняющим», «осуществляющим» или «реализующим» (или называться другими терминами, имеющими аналогичный смысл) функцию или процесс, специалистам в данной области техники очевидно, что такое выполнение может быть технически реализовано аппаратными и/или программными средствами в зависимости от конкретных требований. Оператор сети AN или изготовитель/поставщик прокси-модуля 100, являющийся третьей стороной, может соответствующим образом сконфигурировать прокси-модуль 100 (например, посредством конфигурации обрабатывающего блока 112 на основе аппаратных и/программных средств) согласно конкретным требованиям оператора сети AN.

Как показано на фиг. 6, в одном варианте память 114 в прокси-модуле 110 также может хранить различную межуровневую информацию (также называемую «межуровневыми параметрами») 116 и делает эту информацию доступной блоку PCU 112, когда это необходимо, поддерживая блок PCU 112 в ходе активации оператора сотовой сети AN в отношении доступа ко всей необходимой межуровневой информации для активации M2M услуг в сотовой сети AN 84. Как упоминалось ранее, в одном варианте межуровневыми параметрами является «внешний» идентификатор устройства/шлюза (такие, как например, ранее упомянутые межуровневые идентификаторы M2M устройств/шлюзов. В одном варианте эти межуровневые параметры могут находиться на M2M устройстве/шлюзе, а прокси-модуль может извлекать их из M2M устройства/шлюза. В варианте, где M2M сервер (или другой аналогичный элемент) в сети поставщика услуг (SP) запоминает указанную информацию (которая также может быть извлечена из устройства/шлюза), прокси-модуль может впоследствии получить эту информацию от указанного сервера. Прокси-модуль 100 средств M2M SC может взаимодействовать с сотовой сетью CN 78 и сетью 82 поставщика SP (в частности, это может быть сервер 102 средств M2M SC в варианте на фиг. 4) через интерфейсный блок 118, который может в некоторых вариантах включать в себя IWKF 80 в качестве опции (как показано в виде пунктирного блока на фиг. 6). Интерфейсный блок 118 также может быть соединен с PCU 112 и может выполнять необходимые функции по взаимодействию, поддерживаемые прокси-модулем, посредством команд, поступающих от PCU 112.

PCU 112 может включать в себя, например, процессор общего назначения, специализированный процессор, обычный традиционный процессор, цифровой процессор сигналов (DSP), множество микропроцессоров, один или несколько микропроцессоров, связанных с ядром DSP, контроллер, микроконтроллер, прикладные специализированные интегральные схемы (ASIC), вентильные матрицы, программируемые пользователем (FPGA), интегральные схемы (IC) любого другого типа и/или конечный автомат. PCU 112 может использовать распределенную обработку в некоторых вариантах осуществления изобретения.

Как упоминалось ранее, обсужденные выше функциональные возможности прокси-модуля могут быть реализованы в виде компьютерной программы, программного или программно-аппаратного обеспечения, внедренного в считываемый компьютером носитель данных (например, память 114 на фиг. 6) для их выполнения компьютером общего назначения или процессором (например, блоком PCU 112 на фиг. 6). Примеры считываемых компьютером запоминающих носителей включают память только для считывания (ROM), память с произвольным доступом (RAM), цифровой регистр, кэш-память, полупроводниковые запоминающие устройства, магнитные носители, такие как внешние жесткие диски, магнитные ленты и съемные диски, магнитооптические носители и такие оптические носители, как компакт-диски (CD-ROM), и цифровые универсальные диски (DVD). В некоторых вариантах в памяти 114 могут использоваться распределенные средства хранения данных с/без избыточности.

Альтернативные варианты прокси-модуля 100 средств M2M SC могут включать в себя дополнительные компоненты, предназначенные для обеспечения дополнительных функциональных возможностей, включая любую из обсужденных выше функциональных возможностей, и/или любые функциональные возможности, необходимые для поддержки технического решения, согласующегося с описанными выше основополагающими принципами настоящего изобретения. Заметим, что дополнительные детали архитектуры прокси-модуля 100 на фиг. 6 не показаны просто в целях упрощения иллюстраций. Таким образом, устройства ввода/вывода (I/O) (например, компьютерная клавиатура, сенсорный экран, компьютерный монитор, компьютерная мышь, подключенные к или связанные с прокси-модулем 100, на фиг. 6 не показаны. Однако очевидно, что с прокси-модулем 100 для выполнения различных функций, относящихся к прокси-модулю, которые обсуждались в конкретных вариантах настоящего изобретения, можно использовать различные устройства/системы ввода/вывода или другие внешние устройства/системы (которые могут функционировать вместе с прокси-модулем 100 средств M2M SC).

Раздел II: Маршрутизация некоторых M2M услуг в гостевой сети доступа при предоставлении других услуг через домашнюю сеть доступа

Когда некоторые M2M устройства и/или шлюзы переходят в гостевую сотовую сеть доступа (не показана) (например, когда такие устройства/шлюзы смонтированы на мобильном объекте, таком как, например, грузовик, самолет и т.д.), которая разворачивает средства M2M SC (например, M2M SC 42 в универсальной архитектуре по фиг. 3), и при этом в домашней сети доступа (сети указанных устройств/шлюзов) не развернуты средства M2M SC в их сотовой сети доступа, у домашней сети доступа (не показана) остается возможность разрешить оператору гостевой сотовой сети доступа направить сигнализацию, касающуюся некоторых M2M услуг, и трафик локальным образом (то есть через гостевую сеть, но без прохождения через домашнюю сеть доступа) поставщику M2M услуг (который может представлять собой гостевой M2M SP или домашний M2M SP).

Когда M2M устройство/шлюз заходит в (гостевую) сотовую сеть доступа, домашняя сотовая сеть доступа, на основе действий оператора локальной домашней сети доступа и политики абонента M2M доступа, может указать (например, во время аутентификации пользователя, на основе соглашений об уровнях услуг (SLA) между операторами домашней и гостевой сети, и т.д.) на гостевую сеть доступа, куда может быть непосредственно и локально направлен трафик для сети поставщика M2M услуг (которая, как упоминалось ранее, может являться гостевым M2M SP или домашним M2M SP). В одном варианте использование средств M2M SC (например, средств M2M SC 42 в универсальной архитектуре по фиг. 3, как упоминалось ранее) в качестве прокси-модуля в гостевой сотовой сети доступа (по аналогии с конфигурацией, показанной на фиг. 4), может обеспечить гостевую сотовую сеть доступа информацией, которая необходима ей для того, чтобы иметь доступ к межуровневой информации на всех уровнях, которая необходима для того, чтобы гостевая сеть могла локально направлять указанный трафик. В одном варианте изобретения техническое решение, касающееся маршрутизации специфического трафика через гостевую сотовую сеть доступа, также может быть основано на политики поставщика M2M услуг и/или на подписке на M2M услуги M2M устройства/шлюза (что более подробно обсуждается в Части 2 ниже со ссылками на сеть доступа 3GPP). Эта информация о политики и подписке может быть сконфигурирована статически (и храниться, например, в прокси-модуле средств M2M SC в гостевой сети доступа) или сообщаться динамически (от соответствующего поставщика услуг в гостевую сеть доступа) на основе установившегося в прошлом взаимопонимания между M2M SP и оператором (гостевой) сети AN. В этом случае соединение архитектуры на основе прокси-модуля гостевой сотовой сети с домашним M2M SP может быть подобным соединению, показанному на фиг. 4.

Раздел III: Приведенные в качестве примера варианты архитектуры, имеющие своей целью активацию M2M услуг для сотовой сети доступа

На фиг. 7 схематически представлены приведенные в качестве примера варианты архитектуры для активации M2M услуг для сотовой сети AN (например, сети AN 84 или 86 на фиг. 3). На фиг. 7 эти варианты представлены в упрощенном виде, чтобы к ним было легко обращаться в дальнейшем при подробном осуждении. Как показано в блоке 125 на фиг. 7, эти варианты архитектуры можно разделить на две обширные категории в зависимости от того, развернуты или нет общие средства M2M SC (например, M2M SC 42 на фиг. 3) в сотовой сети AN. Если M2M SC в сотовой сети AN есть, то тогда четыре случая 127-130 относятся к ситуации, когда оператор сотовой сети AN имеет соглашение об уровнях обслуживания (SLA) с поставщиком M2M услуг (SP): случай - 2 (блок 127) относится к ситуации, когда M2M SC развернуты в сотовой сети AN, в то время как M2M SP соответственно не должен разворачивать M2M SC; в случае 3.1 (блок 128) M2M SP использует совместимую архитектуру уровня M2M SL, не являющуюся архитектурой, разработанной Институтом ETSI; случай -4 (блок 129) относится к ситуации, когда сотовая сеть AN и M2M SP разворачивают как те, так и другие вышеупомянутые средства M2M SC (по аналогии с вариантом на фиг. 4); и случай-5 (блок 130) относится к ситуации, когда сотовая сеть AN (разворачивающая M2M SC) является гостевой сетью доступа, домашняя сеть доступа не разворачивает M2M SC, а M2M SP (который может быть домашним M2M SP или гостевым M2M SP) может разворачивать, либо не разворачивать средства M2M SC. Когда в сотовой сети AN средства M2M SC развернуты, но оператор сотовой сети не имеет соглашения SLA с M2M SP, то можно обратиться к случаю-6.1 (блок 131), который может быть реализован по аналогии со случаем-3.1 (блок 128). Наконец, оператор сотовой сети AN может предложить свои собственные M2M услуги в качестве M2M SP, как показано в случае-7 (блок 132) на фиг. 7. С другой стороны, когда средства M2M SC в сотовой сети AN не развернуты, то тогда два случая 134-135 относятся к ситуации, в которой оператор сотовой сети AN имеет соглашение SLA с M2M SP; случай-1 (блок 134) относится к ситуации, в которой средства M2M SC развернуты в сети SP, когда сотовая сеть AN предлагает транспортные и иные услуги; и случай-3.2 (блок 135) относится к ситуации, в которой M2M SP использует архитектуру, отличную от архитектуры ETSI M2M SL. Наконец, когда средства M2M SC в сотовой сети AN не развернуты, и оператор сотовой сети AN не имеет соглашения SLA с поставщиком M2M SP, то можно перейти к случаю-6.2 (блок 136), который можно реализовать по аналогии со случаем- 3.2 (блок 135).

Далее подробно описывается каждый из вариантов архитектуры, идентифицированных на фиг. 7. Очевидно, что все обсуждаемые ниже варианты архитектуры для активации M2M услуг (показанные на фиг. 7) могут поддерживаться при использовании конкретных вариантов настоящего изобретения в сотовой сети AN, предлагающей M2M услуги. Кроме того, очевидно, что в случаях (то есть случаи, показанные в блоках 127-132), когда предполагается использование средств M2M SC в сотовой сети AN, средства M2M SC могут быть развернуты либо в виде сервера средств M2M SC, либо в виде прокси-модуля средств M2M SC. Однако в некоторых вариантах могут быть развернуты одни и те же средства M2M SC для функционирования двумя различными способами в зависимости от архитектуры сети: в качестве сервера средств M2M SC для одного поставщика услуг (SP1) и в качестве прокси-модуля средств M2M SC для другого поставщика услуг (SP2).

Случай-1: В этом случае в сети 82 поставщика услуг M2M SP разворачиваются общие средства M2M SC, например, M2M SC 42 на (фиг. 3) (например, в виде сервера M2M SP), в то время как сотовая сеть AN (которая может иметь соглашение SLA с M2M SP) предлагает транспортные и иные услуги (как показано в блоке 134 на фиг. 7). Этот случай ранее назывался «Опция 1» на фиг. 3, то есть речь идет о тесно связанной архитектуре M2M услуг, в которой средств M2M SC 42 связаны с M2M приложением (приложениями) (через сервер M2M AS 62) и которая развернута в сети 82 поставщика M2M услуг. Эта опция может оказаться негибкой, и для нее может потребоваться сеть M2M SP для поддержки интерфейсов для обеспечения взаимодействия с сотовой сетью доступа каждого типа, чтобы предлагать M2M услуги через упомянутую сотовую сеть доступа. Также может потребоваться, чтобы сеть поставщика M2M SP предоставляла межуровневую информацию о M2M устройстве и приложении M2M услуг обратно в сотовую сеть доступа, чтобы эта сотовая сеть доступа была способна активировать M2M услуги более координированным образом. Если вышеупомянутая межуровневая информация обратно в сотовую сеть доступа не подается, то тогда возможно понадобится, чтобы эта сотовая сеть доступа обеспечила «битпайп» для сети M2M SP (то есть, чтобы сотовая сеть AN могла обеспечивать транспортировку на более высокий уровень услуг (поставщика услуг SP), но без знания о том, что выполняется на ее транспортном уровне). Указанная опция не является гибкой и не обеспечивает разнообразие предложений по M2M услугам.

Случай-2: В этом случае средства M2M SC 42 разворачиваются в виде сервера M2M SC (не показан) в сотовой сети AN 84 (фиг. 3), когда обслуживающему поставщику M2M услуг 88 (который может иметь соглашение SLA с оператором сотовой сети AN) нет необходимости разворачивать средства M2M SC в своей сети (как показано в блоке 127 на фиг. 7). Этот случай соответствует ранее обозначенной «Опции 2» на фиг. 3, то есть слабо связанной или распределенной архитектуре M2M услуг, в которой средства M2M SC 42 отделены от M2M приложения (приложений) и от M2M AS 62 (то есть, средств M2M SC не разворачиваются в одной и той же сети вместе с M2M приложением (приложениями)). Эта опция разворачивания позволяет поставщику M2M SP 88 не поддерживать функцию взаимодействия (например, IWKF 80 на фиг. 3) с сотовой сетью доступа за исключением взаимодействия на уровне приложения между сервером M2M AS 62 (в сети SP) и сервером средств M2M SC (не показан), который находится в сотовой сети доступа. Эта опция дает возможность оператору сотовой сети доступа иметь доступ к межуровневой информации, которая позволяет сотовой сети доступа предлагать активацию M2M услуг более интеллектуальным образом. Эта опция также позволяет поставщику M2M услуг предлагать M2M услуги через множество сетей доступа, если эта сеть доступа поддерживает одну и ту же архитектуру M2M SL (например, архитектуру, совместимую с вариантом архитектуры, разработанным Институтом ETSI). Кроме того, этот случай позволяет обеспечить более высокую гибкость при выписке счетов в сотовой сети доступа и при обеспечении должного качества обслуживания (QoS) в соответствии с характеристиками M2M приложения.

Случаи 3.1 и 3.2: Эти случаи (блоки 128 и 135 на фиг. 7) относятся к поддержке M2M услуг для сети M2M SP, где используется архитектура уровня M2M SL, не соответствующая разработке Института ETSI. В обоих этих случаях предполагается наличие соглашения (SLA) между оператором сети AN и поставщиком M2M услуг. Случай 3.1 относится к ситуации, когда поставщик M2M услуг поддерживает архитектуру уровня M2M SL, которая отличается от архитектуры, определенной Институтом ETSI (например, предпочтительная архитектура 10 ETSI на основе общих средств M2M SC фиг. 1)), а сотовая сеть AN разворачивает средства M2M SC (например, общие M2M SC 42 на фиг. 3) в виде сервера M2M SC. Случай 3.2 относится к ситуации, когда сеть AN не разворачивает средства M2M SC (то есть сеть AN не имеет сервер M2M SC, как в случае 3.1), но сеть поставщика SP все же поддерживает архитектуру, не соответствующую разработке ETSI M2M SL.

На фиг. 8А в качестве примера показана архитектура 140 активации M2M услуг (не соответствующая архитектуре, разработанной Институтом ETSI) для сотовой сети AN (например, AN 84 на фиг. 3), относящаяся к случаю 3.1 на фиг. 7, в то время как на фиг. 8В в качестве примера показана другая архитектура 152 активации M2M услуг (не соответствующая архитектуре, разработанной Институтом ETSI) для сотовой сети AN (например, AN 86 на фиг. 3), относящейся к случаю 3.2 на фиг. 7. Хотя на фигурах 8А-8В показаны разные сетевые элементы 3GPP и разные варианты развертывания средств M2M SC, и хотя такое графическое представление позволяет технически различать архитектуры на фиг. 3 и архитектуры на фигурах 8А-8В, для облегчения обсуждения аналогичные сетевые элементы или компоненты (например, базовая сеть 78, сервер M2M AS 62, M2M ядро 74 и т.д.) на фиг. 3 и фигурах 8А-8В обозначены с использованием подобных ссылочных позиций. Таким образом, базовую сеть 78 на фигурах 8А-8В можно рассматривать как конкретную реализацию (на основе 3GPP) универсальной сети CN 78 на фиг. 3. Аналогичным образом, M2M ядро 74 на фигурах 8А-8В также можно считать конкретной версией (на основе 3GPP) универсального M2M ядра 74 на фиг. 3. Однако для упрощения и облегчения обсуждения указанные конкретные реализации, по существу являющиеся лишь примерами, здесь не отличаются (путем использования разных ссылочных позиций) от их универсальных аналогов на фиг. 3. С другой стороны, поскольку сеть поставщика услуг (SP) на фигурах 8А-8В не основана на архитектуре уровня M2M SL, совместимой с архитектурой ETSI, эта сеть поставщика услуг (SP) идентифицирована с использованием ссылочной позиции «150», которая отличается от ссылочных позиций, использованных для сети поставщика (SP) на фиг. 3.

Как показано на фиг. 8А, сотовая сеть AN 84 (для удобства названная здесь «транспортной сетью») может представлять архитектуру, связанную с «опцией 2» на фиг. 3, описанной ранее. Таким образом, сеть 84 доступа/транспортная сеть представляет вторую сетевую конфигурацию (NT2) по фиг. 3, в которой разворачиваются средства M2M MC (здесь в виде сервера 141 M2M SC на фиг. 8А). Как упоминалось ранее, при разворачивании общих средств M2M SC 42 в виде сервера средств M2M SC (здесь в виде сервера 141 средств M2M SC), средства D/G-SC используют этот сервер средств M2M SC для регистрации M2M услуг. Для упрощения обсуждения сотовая транзитная часть 76 на фигурах 8А и 8В не показана. На фигурах 8А-8В показано, что M2M ядро 74 включает в себя домашний абонентский сервер (HSS) 142 наряду с другими элементами развитого пакетного ядра 3GPP (EPC) 78, такой как, например, сервер 143 аутентификации, авторизации и учета (AAA) 3GPP, 3GPP2 AAA 144, обслуживающий шлюз eHRPD (HSGW) 145 (где «eHRPD» - развитая технология высокоскоростной передачи пакетных данных), функцию, контролирующую выполнение правил работы в сети и учет стоимости, (PCRF) 146 и шлюз PDN (P-GW) 147 (где «PDN» - это сеть пакетной передачи данных). На фигурах 8А-8В также показаны соединения между элементами 143-147 EPC. Функциональные возможности этих элементов 143-147 EPC хорошо известны, и поэтому эти элементы здесь подробно не обсуждаются, поскольку эти подробности не важны для настоящего обсуждения. Однако заметим, что на фигурах 14-16, которые обсуждаются ниже, в Части 2, предусмотрены указанные дополнительные детали, в том числе некоторые из этих элементов.

В варианте на фиг. 8А показано, что IWKF 80 находится на сервере 141 средств M2M SC. В других вариантах, как упоминалось ранее, IWKF 80 может находиться в сотовой сети AN, но при этом не обязательно на M2M сервере сети AN. На фигурах 8А-8В также отмечены соединения на основе API (между сервером 141 средств M2M SC и сервером M2M AS на фиг. 8А и между IWKF 80 и AS 62 на фиг. 8В) наряду с линиями 23А-23С радиосвязи на основе eHRPD/LTE. На фигурах 8А-8В сеть 150 поставщика M2M SP на основе архитектуры (не соответствующей архитектуре, разработанной Институтом ETSI) идентифицирована как «услуга (другая)» (или как другие M2M услуги, или M2M SL-OTH, как упоминалось ранее), чтобы отличить ее от конфигураций 82, 88 на фиг. 3, соответствующих архитектуре, разработанной Институтом ETSI. Таким образом, на фиг. 8В ссылочная позиция «86» по фиг. 3 используется для идентификации конфигурации сети доступа/транспортной сети или NT1), которая не разворачивает средства M2M SC. По причине отсутствия в сотовой сети AN 86 по фиг. 8В сервера M2M SC или прокси-модуля M2M SC функция IWKF 80 может быть использована в сети AN 86 для взаимодействия с сетью 150 поставщика услуг (SP) (не соответствующей архитектуре, разработанной Институтом ETSI) с целью активации предоставления M2M услуг в сотовой сети AN 86. Остальные сетевые элементы или объекты на фиг. 8В совпадают с элементами и объектами на фиг. 8А, и поэтому обсуждение указанных элементов/объектов здесь для краткости не повторяется.

Случаи 3.1 и 3.2 показывают, что в некоторых вариантах изобретения неважно, имеет ли сеть AN сервер средств M2M SC или нет. Другими словами, случаи 3.1 и 3.2 относятся к ситуации, в которой независимо от того, развернута ли архитектура ETSI M2M SC в сотовой сети доступа (например, в виде сервера 141 средств M2M SC на фиг. 8А), сотовая сеть AN все же может обеспечивать активацию M2M услуг для сети поставщика M2M услуг, которая разворачивает архитектуру M2M SL, отличную от архитектуры ETSI. Таким образом, эта опция (то есть случаи 3.1. и 3.2) может рассматриваться как опция, подобная случаю 1, обсужденному выше), когда M2M услуги тесно связаны, а сотовая сеть доступа используется в качестве «битпайпа». Чтобы эта опция (то есть случаи 3.1 и 3.2) поддерживала возможность обратной передачи межуровневой M2M информации сетью поставщика M2M услуг в сотовую сеть доступа, возможно окажется необходимым, чтобы сеть поставщика M2M услуг поддерживала интерфейс взаимодействия (например, IWKF 80) для подачи указанной информации обратно в сотовую сеть доступа. Это может быть реализовано вдобавок к интерфейсу взаимодействия (не показан), который необходим для того, чтобы дать возможность сети поставщика IWKF 80 услуг использовать другие услуги сотовой сети доступа (не относящиеся к M2M или MTC).

Случай 4: Этот случай (блок 129 на фиг. 7) представляет архитектуру для активации M2M услуг, в которой сотовая сеть доступа разворачивает средства M2M SC, также как и поставщик M2M услуг M2M. Предполагается, что имеется соглашение SLA между оператором AN и поставщиком M2M услуг. Указанная архитектура может включать в себя компоновки, показанные в опции 1, а также опции 2 на фиг. 3, то есть сотовую сеть AN 84 и сеть 82 поставщика M2M услуг. Таким образом, в одном варианте указанный случай 4 может представлять архитектуру 95, показанную на фиг. 4, где сотовая сеть 84 доступа использует средства M2M SC 42 в виде прокси-модуля 100 средств M2M SC для сервера 102 средств M2M SC в сети 82 поставщика M2M услуг. Этот случай 4 может обеспечить большую гибкость, когда сотовая сеть способна предлагать активацию M2M услуг всем развернутым средствам поставщика M2M услуг, которые соответствуют архитектуре ETSI M2M SL. В случае 4 также возможна поддержка архитектуры, не соответствующей архитектуре ETSI M2M SL. Возможна архитектура с минимальными изменениями, с тем чтобы средства M2M SC (то есть прокси-модуль средств M2M SC в сети AN) также поддерживали минимальные требования, относящиеся к функциональным возможностям, и связанным с архитектурой ETSI M2M SL. Например, когда сеть, не являющаяся сетью ETSI M2M SP, имеет развернутый M2M сервер, сотовая сеть AN может развернуть и сконфигурировать средства M2M SC для функционирования в качестве прокси-модуля M2M SC для этого сервера. С другой стороны, даже в том случае, когда сотовая сеть AN разворачивает средства M2M SC в виде сервера M2M SC, этот M2M сервер сети AN должен быть сконфигурирован для функционирования в качестве прокси-модуля для M2M сервера, не относящегося к поставщику услуг ETSI, с тем чтобы способствовать «связи» между этими двумя разными объектами, один из которых основан на варианте, предложенном Институтом ETSI, а другой нет.

Случай 5: Этот случай (блок 130 на фиг. 7) относится к ситуации, когда M2M устройства/шлюзы находятся в роуминге. В этом случае сотовая сеть AN является гостевой сетью (не показана), которая разворачивает средства M2M SC (одним из способов, показанных на фиг. 3), домашняя сеть не разворачивает средства M2M SC, а поставщик M2M услуг может, но не обязательно, развернуть средства M2M SC. Вдобавок к соответствующему соглашению SLA с гостевой сетью, оператор домашней сети также может иметь соглашение (SLA) с поставщиком M2M услуг (который может представлять собой гостевой M2M SP или домашний M2M SP), либо в одном варианте домашний и гостевой поставщики услуг могут иметь соглашение SLA друг с другом. Такая компоновка обсуждается в разделе II, приведенном выше. В итоге заметим, что этот случай позволяет направлять M2M услуги через гостевую сотовую сеть доступа на основе политики домашней сети AN и M2M подписки (M2M устройства/шлюза). Эта опция также может обеспечить большую гибкость и больший объем управления, позволяющий домашней сотовой сети доступа предоставлять гостевой сотовой сети доступа возможность непосредственно (то есть без участия домашней сети) направлять некоторые M2M услуги через свою гостевую сеть, используя средства M2M SC гостевой сети (которые были сконфигурированы для функционирования в качестве сервера и/или прокси-модуля, как упоминалось выше).

Случаи 6.1 и 6.2: Эти случаи (блоки 131 и 136 на фиг. 7) относятся к активации M2M услуг сотовой сетью доступа, когда оператор сети AN не имеет соглашения (SLA) с поставщиком M2M услуг. Для этих случаев, когда оператор сотовой сети доступа не имеет действующего SLA с поставщиком M2M услуг, активация M2M услуг для сотовой сети доступа аналогична ситуации, показанной на фигурах 8А и 8В (то есть случаи 3.1 и 3.2, обсужденные выше), когда сотовая сеть доступа обеспечивает транспортные и иные услуги для поставщика M2M услуг, который разворачивает архитектуру, не являющуюся архитектурой ETSI M2M SL. Таким образом, в этой опции не имеет значения, имеет ли сотовая сеть доступа средства M2M SC (сервер/прокси-модуль); сотовая сеть доступа может продолжать выполнять активацию M2M услуг, как было описано ране со ссылками на фигуры 8А-8В. Однако, если SLA устанавливается в динамическом режиме (например, в момент предоставления M2M услуги объекту M2M связи) между оператором сети AN и поставщиком услуг (SP), то тогда сотовая сеть AN может обеспечить активацию M2M услуг согласно одному из разных случаев, описанных выше.

Случай 7: В этом случае оператор сотовой сети доступа предлагает свои собственные M2M услуги в качестве поставщика M2M услуг. В связи с этим могут возникнуть два подслучая: (А) Когда сотовая сеть доступа разворачивает средства M2M SC (в качестве сервера M2M SC) в своей собственной сети (блок 132 на фиг.7), можно ожидать следующего: (i) нет изменений, касающихся оператора сотовой сети AN, и можно использовать архитектуру для активации M2M услуг в виде опции 2 на фиг. 3 с сетью M2M услуг, являющейся частью сотовой сети доступа; (ii) оператор сотовой сети AN уже развернул средства M2M SC в виде M2M сервера в своей сети и может поместить IWKF 80 в M2M сервер; (iii) оператор сотового доступа может использовать идентификатор подписки сети доступа (объекта M2M связи) для обращения к подписке на M2M услуги. (В) В случае, когда оператор сотовой сети AN не разворачивает средства M2M SC в собственной сети, можно ожидать следующего: (i) для совместимости с M2M архитектурой ETSI оператору сети AN может понадобиться развернуть средства M2M SC в своей сети любым способом, дающим возможность предоставления его собственных M2M услуг своим подписчикам; (ii) если оператор сети AN все же предпочитает не разворачивать средства M2M SC, то тогда он может столкнуться с проблемами масштабирования для поддержки разных M2M услуг способом, совместимым с требованиями ETSI.

Раздел IV: Примерные варианты активации M2M услуг сотовой сетью доступа согласно принципам настоящего изобретения

Далее описывается сущность приведенных в качестве примера вариантов настоящего изобретения (которые обеспечивают более высокую гибкость при активации разворачивания M2M услуг сотовой сетью AN или любой другой сетью доступа, если эта сеть доступа поддерживает архитектуру ETSI M2M SL или любую архитектуру, которая соответствует концепциям, лежащим в основе архитектуры ETSI), обсужденных ранее в разных разделах (и проиллюстрированных в виде разных случаев на фиг. 7) в данной Части 1.

Вариант 1. В этом варианте средства M2M SC (например, общие средств M2M SC 42, показанные на фиг. 3) разворачиваются и используются внутри сотовой сети AN в виде прокси-модуля средств M2M SC в тракте сигнализации между средствами G/D-SC и сервером средств M2M SC в сети M2M SP, показанной на фиг. 4, что обеспечивает оптимизацию архитектуры для активации M2M услуг для сотовой сети AN. В данном варианте средства M2M SC поддерживают функциональные возможности сервера M2M SC и также используются в виде прокси-модуля для сервера средств M2M SC, который находится внутри сети поставщика M2M услуг. Прокси-модуль средств M2M SC может иметь доступ ко всем M2M устройствам и/или межуровневой информации от шлюзов, которую используют для активации услуг M2M (в сотовой сети AN) и обеспечения необходимой синхронизации между сетью M2M SP и сотовой сетью доступа (например, для повышения качества обслуживания (Q0S), достижимости M2M устройств/шлюзов, правильной выписки счетов и т.д.). Использование средств M2M SC в виде прокси-модуля может сократить объем M2M сигнализации и трафика взаимодействия между сетью M2M SP и сотовой сетью AN путем обеспечения (сотовой сетью AN) легкого доступа к межуровневой информации M2M устройства и/или шлюза. В этом варианте сеть поставщика M2M SP может осуществлять связь с сотовой сетью доступа через интерфейс API между сервером средств M2M SC и прокси-модулем средств M2M SC внутри сотовой сети доступа. Этот интерфейс может скрывать услуги, характерные для сотовой сети доступа (например, поддержка RAN, коммутация, маршрутизация, выписка счетов и т.д.) от сети поставщика M2M услуг.

Вариант 2. В этом варианте прокси-модуль средств M2M SC используется для способствования маршрутизации некоторой части трафика M2M услуг через гостевую сеть доступа, когда M2M D/G находится в роуминге в сотовой сети доступа (то есть в гостевой сети), отличной от домашней сети доступа (как было показано выше в разделе II). В этом варианте домашняя сотовая сеть доступа может использовать сервер средств M2M SC в сети поставщика M2M SP (который может быть домашним M2M SP или гостевым M2M SP). Когда M2M устройство и/или M2M шлюз переходят в гостевую сотовую сеть доступа, которая разворачивает и использует прокси-модуль средств M2M SC, домашняя сотовая сеть доступа способна указать гостевой сотовой сети доступа, что конкретные M2M услуги могут направляться непосредственно гостевой сетью (то есть без участия домашней сети) в сеть M2M SP. Это указание от домашней сотовой сети доступа гостевой сотовой сети доступа может быть основано на политики домашней сотовой сети доступа и/или подписке на M2M доступ/транспортировку (M2M устройства/шлюза). Также это может быть основано на политики сети поставщика M2M услуг и/или на подписке на M2M услуги (M2M устройства/шлюза). Некоторые из M2M услуг могут быть направлены через гостевую сотовую сеть доступа в гостевую сеть M2M SP на основе соглашения (SLA) между домашним и гостевым поставщиками M2M услуг.

Вариант 3. Этот вариант с точки зрения M2M SP находится в контексте фиг. 4 (как вариант 1, обсужденный выше). В этом варианте сеть средств M2M SP использует прокси-модуль средств M2M SC внутри сотовой сети AN для предоставления сотовой сети AN прямого доступа к межуровневой информации M2M устройства и/или шлюза поставщика услуг (SP) (например, межуровневый идентификатор M2M устройства, который используется для идентификации M2M устройства через интерфейс между оператором сети AN и поставщиком M2M услуг) в целях активации M2M услуг (например, маршрутизация, нахождение и оценка достижимости устройства, QoS, выписка счетов, и т.д.). Сервер средств M2M SC внутри сети поставщика услуг может взаимодействовать с прокси-модулем средств M2M SC внутри сотовой сети доступа на уровне приложений. Таким образом, сеть M2M SP может не поддерживать необходимые функциональные возможности взаимодействия для сотовой сети доступа.

Вариант 4. Этот вариант с точки зрения оператора сотовой сети AN находится в контексте фиг. 4 (как вариант 1, обсужденный выше). Прокси-модуль средств M2M SC используется внутри сотовой сети доступа для активации M2M услуг и связи с сетью M2M SP, которая разворачивает и использует сервер M2M SC. В этом варианте прокси-модуль средств M2M SC внутри сотовой сети AN используют для предоставления сотовой сети доступа всей необходимой межуровневой информации для M2M устройства и/или шлюза, которые обслуживаются сетью поставщика M2M услуг, разворачивающей и использующей сервер средств M2M SC.

Вариант 5. Этот вариант относится к сети M2M SP, которая использует архитектуру M2M SL, совместимую с архитектурой, не являющейся архитектурой ETSI (например, подобную конфигурациям на фигурах 8А-8В) и также использует интерфейс взаимодействия для подачи межуровневой информации для M2M устройства и/или M2M шлюза обратно в сотовую сеть доступа в целях активации M2M услуг (например, маршрутизация, нахождение и достижимость устройства, QoS, выписка счетов, и т.д.). В данном варианте сеть средств M2M SP называется «другая сеть M2M услуги». Здесь сеть M2M SP может передавать свой трафик M2M услуг (сигнализация и данные) на транспортном уровне, то есть через сотовую сеть доступа. В этом случае сеть M2M SP может поддерживать интерфейс взаимодействия для сотовой сети доступа для обратной подачи межуровневой информации M2M устройств и/или M2M шлюзов, которые зарегистрированы у поставщика услуг (SP), и также может использовать транспортировку сотовой сети доступа, чтобы дать возможность сотовой сети доступа активировать архитектуру M2M услуг (в таких целях, как, например, маршрутизация, нахождение и достижимость устройства, QoS, выписка счетов, и т.д.). Интерфейс взаимодействия между сетью М2М SP и сотовой сетью доступа может быть реализован посредством связи с прокси-модулем/сервером средств M2M SC в сотовой сети доступа. Это означает, что прокси-модуль/сервер средств M2M SC в сотовой сети AN может поддерживать взаимосвязь (например, через IWKF 80) с функциональными возможностями, совместимыми с архитектурой уровня M2M SL, которая поддерживается сетью поставщика M2M услуг.

Вариант 6. В этом варианте, как и в случае 1 на фиг. 7, сеть M2M SP использует сервер средств M2M SC и интерфейс взаимодействия для обратной подачи межуровневой информации M2M устройства и/или шлюза в сотовую сеть доступа в целях активации M2M услуг (например, маршрутизация, нахождение и достижимость устройства, QoS, выписка счетов, и т.д.). В этом варианте сотовая сеть AN не разворачивает и не использует сервер/прокси-модуль средств M2M SC, в то время как сеть M2M SP разворачивает и использует сервер средств M2M SC. В этом случае сеть M2M SP поддерживает и использует интерфейс взаимодействия с сотовой сетью AN для обратной подачи всей необходимой межуровневой информации в сотовую сеть доступа. Это означает, что при регистрации сервером средств M2M SC в сети M2M SP приложения M2M на M2M устройстве и/или шлюзе сервер M2M SC может обратиться (и извлечь) к межуровневой информации, которая относится к M2M устройствам и/или шлюзам (и запомнить ее, например, в данном устройстве/шлюзе) посредством сигнализации на уровне M2M SL (между устройством/шлюзом и M2M сервером) и может затем послать эту информацию в сотовую сеть через интерфейс взаимодействия.

Вариант 7. В этом варианте поставщик M2M SP, который не имеет действующего соглашения с оператором сотовой сети AN (как обсуждалось ранее, например, в контексте случаев 6.1 и 6.2, показанных на фиг. 7), использует интерфейс взаимодействия для обратной подачи межуровневой информации M2M устройства и/или шлюза в сотовую сеть доступа в целях активации M2M услуг (например, маршрутизация, нахождение и достижимость устройства, QoS, выписка счетов, и т.д.). В этом варианте сеть M2M SP не имеет действующего соглашения (SLA) с оператором сотовой сети AN, но M2M SP поддерживает архитектуру ETSI M2M SL. В этом варианте, вне зависимости от разворачивания средств M2M SC в сотовой сети доступа и сети M2M SP, ситуация с взаимодействием может быть аналогична вариантам 5 и 6, обсужденным выше (где поставщику M2M услуг необходимо предоставить сотовой сети AN требуемую межуровневую информацию для всех зарегистрированных M2M устройств и/или шлюзов. В случае, когда сеть M2M SP способна установить динамическое SLA с сотовой сетью доступа, архитектура активации M2M услуг может соответствовать любому из других случаев, обсужденных выше или обсуждаемых ниже, в зависимости от разворачивания сервера/прокси-модуля средств M2M SC.

Вариант 8. В этом варианте сеть M2M SP, которая не имеет действующего соглашения SLA с сотовой сетью AN, но поддерживает архитектуру ETSI M2M SL, использует динамически установленное SLA (например, во время обеспечения связи для объекта M2M связи) для активации сервера средств M2M SC внутри сотовой сети AN, чтобы иметь доступ к межуровневой информации на основе SP для M2M устройств или шлюзов (которые связаны/зарегистрированы у поставщика M2M SP) в целях активации M2M устройств (например, маршрутизация, нахождение и достижимость устройства, QoS, выписка счетов, и т.д.) через сотовую сеть AN. Сети поставщика M2M услуг разрешается установить динамическое соглашение SLA с сотовой сетью доступа. В этом смысле данный вариант может быть аналогичен случаю 2, показанному на фиг. 7 в блоке 127.

Вариант 9. В этом варианте сеть M2M SP (которая не имеет действующего SLA с сотовой сетью AN, но поддерживает архитектуру ETSI M2M SL) использует динамически установленное SLA для того, чтобы предоставить прокси-модулю M2M SC внутри сотовой сети AN возможность доступа к межуровневой информации на основе SP для M2M устройств или шлюзов (которые связаны с M2M SP/зарегистрированы у поставщика M2M услуг) с целью активации M2M услуг (например, маршрутизация, нахождение и достижимость устройства, QoS, выписка счетов, и т.д.) через сотовую сеть AN. Сети M2M SP предоставляется возможность установить динамическое SLA с сотовой сетью доступа. В этом варианте сеть M2M SP (на основе динамически установленного SLA с сотовой сетью AN) использует связь между сервером средств M2M SC внутри его сети и прокси-модулем средств M2M SC в сотовой сети доступа для предоставления сотовой сети доступа к необходимой межуровневой информации. В этом отношении данный вариант может быть аналогичен варианту 3, описанному выше.

Вариант 10. В этом варианте сеть M2M SP имеет архитектуру уровня M2M SL, несовместимую с архитектурой ETSI, и здесь используется прокси-модуль M2M SC внутри сотовой сети AN для направления сигнализации об услугах (SL сигнализация) от/на M2M устройство и/или шлюз, с тем чтобы предоставить сотовой сети AN возможность обращения к межуровневой информации для M2M устройства и/или шлюза в целях активации M2M услуг (например, маршрутизация, нахождение и достижимость, выписка счетов, и т.д.). В этом варианте сеть M2M SP не поддерживает архитектуру ETSI M2M SL, но имеет соглашение SLA с оператором сотовой сети AN для уровня M2M услуг сети M2M SP для взаимодействия с прокси-модулем средств M2M SC (ETSI) внутри сотовой сети AN. В этом варианте сети M2M SP предоставлена возможность динамически устанавливать SLA, если имеются соответствующие средства. В этом варианте сеть M2M SP (на основе установленного соглашения SLA с сотовой сетью AN) может использовать связь между M2M SL и прокси-модулем средств M2M SC сотовой сети AN предоставить сотовой сети AN доступ к межуровневой информации, которая необходима для всех зарегистрированных M2M устройств и/или шлюзов для этого M2M SP c тем, чтобы активировать M2M услуги через эту сотовую сеть AN. Когда уровень SL поставщика M2M услуг (не относящегося к ETSI M2M SL), действует как (или подобно) сервер M2M SC, этот вариант можно считать аналогичным вышеописанному варианту 3.

Вариант 11. В этом варианте M2M услуги для M2M устройства и/или шлюза, находящегося в роуминге, направляются через гостевую сотовую сеть AN непосредственно в соответствующую сеть M2M SP (например, домашнюю сеть M2M SP) на основе политики оператора домашней сотовой сети AN и/или подписки на M2M доступ/транспортировку (для находящегося в роуминге устройства/шлюза). Подобно случаю 5 (блок 130) на фиг. 7, в этом варианте сеть M2M услуг (домашний SP) может поддерживать архитектуру ETSI M2M SL (с M2M сервером внутри его сети и может иметь SLA с оператором (гостевой) сотовой сети AN для предоставления возможности сети M2M SP использовать прокси-модуль M2M SC, развернутый внутри (гостевой) сотовой сети доступа. Вдобавок, сеть M2M SP (домашний) SP может иметь SLA с гостевой сетью M2M SP (гостевой SP). Указанное соглашение (SLA) может поддерживать использование другого сервера средств M2M SC внутри гостевой сети поставщика услуг (SP). Вдобавок, оператор сотовой сети доступа (то есть оператор домашней сети доступа (AO)) может иметь соглашение (SLA) о роуминге с оператором гостевой сотовой сети доступа (гостевой AO). Указанное соглашение о роуминге может разрешать домашним M2M устройствам и/или шлюзам переходить в гостевую сеть AO. Подобно случаю 5, показанному на фиг. 7, в этом варианте домашняя сотовая сеть AN может не разворачивать средства M2M SC. Когда M2M устройство и/или шлюз, которые подписаны на M2M услуги, предложенные домашним SP, переходит в гостевую сеть AO, гостевая сотовая сеть доступа будет иметь возможность направить некоторые из M2M услуг непосредственно домашнему поставщику услуг (SP) (то есть без перехода через домашнюю сеть AO), используя средства M2M SC домашнего поставщика услуг в виде сервера M2M SC. С другой стороны, у гостевой сотовой сети доступа оператора AO будет возможность направлять некоторые M2M услуги в гостевую сеть поставщика услуг (SP), используя средства M2M SC сети AM в виде прокси-модуля M2M SC, на сервер M2M SC в гостевом поставщике M2M услуг (гостевой SP). Решение о направлении услуг M2M устройства и/или шлюза непосредственно из гостевой сотовой сети доступа поставщику M2M услуг (домашнему SP) может быть основано на политики домашнего оператора AO и/или подписке на транспортировку M2M доступа (M2M устройства/шлюза) и/или на основе политики поставщика M2M услуг (домашнего SP) и/или подписки на M2M услуги (M2M устройства/шлюза). Решение о направлении услуг M2M устройства и/или шлюза непосредственно из гостевой сотовой сети доступа соответствующему M2M SP (гостевому SP) может быть основано на политики поставщика M2M услуг (домашнего SP) и/или подписки на M2M услуги. Гибкость направления M2M услуг через гостевую сотовую сеть AN обеспечивают большую гибкость и оптимизацию маршрутизации M2M услуг.

Вариант 12. В этом варианте M2M услуги для находящегося в роуминге M2M устройства и/или шлюза, направляют через гостевую сотовую сеть доступа непосредственно в сеть M2M SP (то есть гостевому SP) на основе политики домашней сети M2M SP устройства/шлюза, находящегося в роуминге, и/или на основе подписки на M2M услуги. Этот вариант перекрывается вариантом 11, описанным выше. Однако необходимо дополнительно заметить, что этот вариант обеспечивает гибкость предложения M2M услуг для M2M устройств и/или M2M шлюзов через географически ближайшего поставщика M2M услуг (например, через гостевого SP), который имеет соглашение SLA с домашним поставщиком M2M услуг устройства/шлюза (домашний SP).

Вариант 13. В этом варианте сотовая сеть AN использует прокси-модуль средств M2M SC для сервера средств M2M SC внутри сети M2M SP (который может быть в сотовой сети AN, то есть являться ее частью), чтобы иметь прямой доступ к межуровневой информации для M2M устройства и/или шлюза в целях активации M2M услуг (например, маршрутизация, нахождение и достижимость устройства, QoS, выписка счетов, и т.д.). Этот вариант распространяется на использование прокси-модуля M2M SC сотовой сетью доступа, которая также может включать в себя сеть M2M SP. В отличие от этого данный вариант аналогичен варианту 4, обсужденному выше.

Вариант 14. В этом варианте сотовая сеть AN использует прокси-модуль M2M SC в виде сервера M2M SC в целях активации M2M услуг (например, маршрутизация, нахождение и достижимость устройства, QoS, выписка счетов, и т.д.) для обслуживания собственных M2M устройств и/или шлюзов. Этот вариант охватывает использование прокси-модуля средств M2M SC в виде M2M сервера в том случае, когда оператор сотовой сети доступа предлагает собственные M2M услуги (по аналогии со случаем 7, показанным в блоке 132 на фиг.7). Оператор сотовой сети AN может использовать идентификатор подписки на M2M доступ M2M устройств/шлюзов для обращения к подписке на M2M услуги для устройств/шлюзов. В противном случае, этот вариант может быть аналогичен варианту 4, обсужденному выше, когда сеть M2M SP рассматривается как часть сети сотового оператора.

Вариант 15. В этом варианте сотовая беспроводная сеть доступа (не обязательно 3GPP) может использовать архитектуру для активации M2M услуг согласно настоящему изобретению (например, универсальную архитектуру, показанную на фиг. 3) для поддержки и использования архитектуры, совместимой с ETSI SL, для предоставления транспортных и иных услуг сети M2M SP. Хотя изобретение в основном описывается в контексте использования сотовой сети доступа как средства доступа для архитектуры активации M2M услуг, все обсуждаемые здесь аспекты настоящего изобретения равным образом применимы к любым другим сетям доступа на основе Протокола IP (например, сеть доступа BBF (Форум широкополосной связи)), которая поддерживает и использует архитектуру ETSI M2M SL.

Вариант 16. В этом варианте основополагающие принципы настоящего изобретения могут быть применены к любой архитектуре уровня M2M SL, в которой используется концепция разделения/распределения общих служебных средств M2M (например, средств M2M SC 42 на фиг. 3) и сервер M2M приложения (приложений), и/или в которой применяются вышеупомянутые принципы, описанные в документах ETSI M2M TC. Хотя данное описание основано на архитектуре ETSI M2M SL, и по всему описанию используются архитектуры, совместимые с ETSI, данное изобретение равным образом применимо к любой архитектуре уровня M2M SL, в которой используются базовые принципы, аналогичные базовым принципам, установленным Техническим комитетом ETSI M2M TC (обсужденным ранее). Другими словами, может быть сконфигурирована любая архитектура уровня M2M SL, которая в основном содержит общие средства M2M SC из M2M AS, и которая соответствует базовым принципам ETSI M2M TC, чтобы придерживаться обсужденных здесь схожих архитектур активации M2M услуг.

ЧАСТЬ 2

В этой части приведены примеры сигнализации и другие подробности реализации архитектуры активации M2M услуг, описанные в Части 1 в контексте сети доступа 3GPP. Эта часть касается различных опций для архитектуры активации M2M услуг (например, для архитектуры 60 на фиг. 3), которые возможны при использовании архитектуры уровня M2M SL согласно ETSI TS 102.69. Как упоминалось выше, эта часть касается особой, приведенной в качестве примера ситуации, когда сотовая сеть доступа на фиг. 3 является сотовой сетью AN 3GPP или другой сетью, в которой используется ядро 3GPP EPC (например, EPC 78, показанное на фиг. 8А-8В) или другая сеть CN, имеющая аналогичные атрибуты. Далее в разделах I-III кратко описываются некоторые допущения и предпосылки технического решения по активации M2M услуг (для доступа 3GPP) согласно конкретным вариантам настоящего изобретения. После этого описывается техническое решение, названное здесь «Техническое решение по активации M2M услуг» (MSES), которое касается следующих двух основных аспектов: (А) начальное подключение M2M объекта для первого обслуживания поставщиком M2M услуг (SP) и (В) последующее постоянное подключение (M2M объекта) тем же самым M2M SP, который использовался во время начального подключения для первого обслуживания. Далее предполагается, что устройство M2M доступа (например, устройство 158 M2M доступа на фиг. 9, обсуждаемой ниже) имеет подписку на M2M доступ от оператора доступа (AO) 3GPP. Эта подписка на M2M доступ может иметь некоторую используемую по умолчанию конфигурацию и может автоматически обновляться согласно процедуре начального подключения услуг, обсуждаемой ниже.

На фиг. 9 показана блок-схема приведенного в качестве примера объекта 155 M2M связи согласно одному варианту настоящего изобретения. M2M объект 155 по существу может быть подобен M2M объекту 50, обсужденному выше со ссылками на фиг. 2. Поэтому подробное обсуждение различных логических элементов, являющихся общими для объектов на фигурах 2 и 9, для краткости здесь не приводится. Обратимся теперь к фиг. 9, где M2M объект 155 может включать в себя процессор 157, память 158 и приемопередатчик 160. Процессор 157 может включать в себя два логических M2M устройства: устройство 162 M2M доступа и устройство 163 M2M услуг. Эти логические устройства 162-163 могут иметь функции, аналогичные соответствующим логическим устройствам 56 и 58 на фиг. 2. Однако в некоторых вариантах эти логические устройства могут обеспечивать (на основе подходящей конфигурации процессора 157 в аппаратной и/или программной части) дополнительные функции, обсуждаемые ниже со ссылками на фигуры 10-16. В некоторых других вариантах эти логические устройства 162-163 могут храниться в памяти 158 и могут быть доступны процессору 157, когда это будет необходимо. В памяти 158 могут храниться, например, средства M2M SC 165, характерные для объекта, одно или несколько M2M приложений 106 и параметры 167 межуровневой информации, характерной для объекта (которые уже обсуждались выше), как показано на фиг. 9. Средства M2M SC 165 могут быть аналогичны средствам M2M SC 54 на фиг. 2, а M2M приложение (приложение 166) может соответствовать M2M приложению 52 на фиг. 2. Поэтому дополнительное обсуждение этих элементов здесь не предусмотрено. Приемопередатчик 160 может осуществлять связь с процессором 157 для выполнения передачи/приема данных, управляющей или другой сигнализирующей информации (через антенный блок 168) на/от сотовой сети AN (здесь это сеть AN 3GPP), с которой M2M объект 155 может осуществлять связь (используя соответствующий 3GPP доступ, такой как, например, eHRPD, LTE и т.д., как показано на фигурах 8А-8В, 11 и 12) для обращения к выбранному объектом поставщику M2M SP для осуществления M2M связи, касающейся соответствующих M2M услуг. Альтернативные варианты объекта 155 M2M связи могут включать в себя дополнительные компоненты, отвечающие за предоставление дополнительных функциональных возможностей, в том числе, любую из идентифицированных здесь функциональных возможностей и/или любые функциональные возможности, необходимые для поддержки упомянутого технического решения согласно основополагающим принципам настоящего изобретения.

В одном варианте M2M объект 155 может быть сконфигурирован (в аппаратном виде, в виде программного обеспечения или того и другого) для реализации активации M2M услуг согласно основополагающим принципам настоящего изобретения. Например, при невозможности модификации аппаратной архитектуры M2M объекта 155 необходимые функциональные возможности для объекта 155 можно получить посредством соответствующего программирования процессора 157. Выполнение программного кода процессором 157 может инициировать выполнение этим процессором (когда это необходимо) процедур поддержки технического решения по активации M2M услуг согласно основополагающим принципам настоящего изобретения. В одном варианте логические устройства 162-163 могут быть реализованы программными средствами и могут быть сконфигурированы согласно основополагающим принципам настоящего изобретения. Таким образом, хотя в обсуждении, приведенном ниже, M2M объект 2155 может относиться к «выполнению», «осуществлению» или «реализации» (или к другим аналогичным терминам) функции, процесса или этапа способа, специалистам в данной области техники очевидно, что это действие можно технически воплотить аппаратными и/или программными средствами, в зависимости от потребностей. Оператор сети AN и/или поставщик M2M SP или третья сторона (например, изготовитель или поставщик M2M объекта 155) могут подходящим образом сконфигурировать M2M объект 155 (например, аппаратными и/или программными средствами в зависимости от конфигурации процессора 157) согласно конкретным требованиям, которые обсуждаются ниже.

Как упоминалось ранее, процессор 157 может находиться на связи с памятью 158 для обработки/извлечения и запоминания соответствующей информации для M2M объекта 155 (например, межуровневые параметры, характерные для объекта, такие как межуровневый идентификатор M2M D/G, программный код M2M приложения и т.д.). Процессор 157 может включать в себя, например, процессор общего назначения, специализированный процессор, традиционный процессор, цифровой процессор сигналов (DSP), множество микропроцессоров, один или несколько микропроцессоров, связанных с ядром DSP, контроллер, микроконтроллер, прикладные специализированные интегральные схемы (ASIC), вентильные матрицы, программируемые пользователем (FPGA), интегральные схемы (IC) любого другого типа и/или конечный автомат. В некоторых вариантах процессор 155 может использовать распределенную обработку. Некоторые либо все описанные здесь функциональные возможности (например, со ссылками на фигуры 10-16), обеспечиваемые M2M объектом (например, M2M объектом 155) могут быть обеспечены процессором 157, выполняющим команды, хранящиеся на носителе данных или считываемом компьютером носителе (носителях) данных, таком как память 158, показанная на фиг. 9. Примеры считываемых компьютером запоминающих носителей включают память только для считывания (ROM), память с произвольным доступом (RAM), цифровой регистр, кэш-память, полупроводниковые запоминающие устройства, магнитные носители, такие как внешние жесткие диски, магнитные ленты и съемные диски, магнитооптические носители и такие оптические носители, как компакт-диски (CD-ROM) и цифровые универсальные диски (DVD). В некоторых вариантах в памяти 114 могут использоваться распределенные средства хранения данных с избыточностью и без избыточности.

РАЗДЕЛ I: ПРОФИЛЬ ПОДПИСКИ НА M2M ДОСТУП

При использовании сети доступа 3GPP (например, E-UTRAN) и 3GPP2 (например, eHRPD на основе CDMA2000) идентификатором подписки на M2M доступ (который может храниться в M2M устройстве/шлюзе с использованием, например, памяти 158, показанной на фиг. 9) может быть международный идентификатор мобильного абонента (IMSI) M2M объекта и/или идентификатор сетевого доступа (NAI) либо другой подобный идентификатор. Как известно, идентификатор IMSI обеспечивает уникальную идентификацию, связанную с мобильным блоком, работающим в сетях GSM, CDMA, EVDO или других сетях мобильной связи. Номер IMSI может храниться в самом мобильном блоке (например, на карте модуля идентификации абонента (SIM) в случае мобильного телефона или UE). Идентификатор NAI относится к другому способу идентификации пользователя, который запрашивает доступ к сети (например, беспроводная IP сеть или ядро 3GPP EPC). Таким образом, идентификатор NAI представляет пользователя, который допущен клиентским устройством (например, M2M объект 155 на фиг. 9) во время аутентификации сетевого доступа. Подписка на M2M доступ для M2M объекта может храниться в сети 3GPP (и в некотором варианте на M2M объекте) и может идентифицировать, используется (или конфигурируется/авторизуется для) ли устройство 162 M2M доступа объекта (фиг. 9) только для M2M услуг, для M2M связи и постоянного доступа в Интернет, только для постоянного доступа в Интернет или для любой другой комбинации. Если сеть 3GPP/3GPP2 идентифицирует, что подписка на доступ относится к обеспечению доступа и транспортного соединения для M2M объекта, то в одном варианте настоящего изобретения предполагается, что вдобавок к другим уже существующим стандартным параметрам конфигурируются следующие параметры в качестве части профиля подписки на доступ объекта (например, в сети доступа):

(i) Имя точки доступа (используемых по умолчанию сетевых служебных средств (N-SC) M2M сети доступа. Имя APN средств N-SC идентифицирует средства N-SC, а также возможную связность в направлении сети. Таким образом, APN используемых по умолчанию средств N-SC может идентифицировать используемые по умолчанию средства M2M SC сети доступа 3GPP, которые могут быть использованы для начального подключения услуг (обсуждается ниже) и обеспечения M2M объекта в соответствии с выбранным поставщиком M2M SP. Из-за частых обсуждений сетевых средств SC и средств SC на основе устройства/шлюза в Части 2 термин «N-SC» используется для различения средств SC на основе сети (будь то сеть AN или сеть SP) и средств SC, характерных для объекта (таких как D/G-SC 165 на фиг. 9). В контексте универсальной архитектуры на фиг. 3 указанные средства N-SC представляют собой версию общих средств M2M SC 42, развернутых в сети.

(ii) Относится ли данная подписка на доступ к M2M устройству или M2M шлюзу, то есть является ли M2M объект 155 (фиг. 9) устройством (в том числе, например, оборудованием UE, способным осуществлять M2M связь, как упоминалось ранее) или шлюзом.

РАЗДЕЛ II: ПРЕДВАРИТЕЛЬНОЕ ОБЕСПЕЧЕНИЕ УСТРОЙСТВА M2M УСЛУГ

Далее следует список заранее сформулированных предположений и предпосылок для устройства M2M услуг (например, устройство 163 на фиг. 9) до начального подключения для первого обслуживания услуг (обсуждаемого ниже) к выбранному поставщику M2M услуг.

(i) Предполагается, что устройство M2M услуг заранее обеспечено (например, оператором сети доступа, в которой соответствующий M2M объект является подписчиком, изготовителем M2M объекта или какой-либо другой стороной, конфигурирующей M2M объект для M2M связи) средствами D/G-SC, которые соответствуют ETSI M2M SL.

(ii) Предполагается, что устройство M2M услуг предварительно обеспечено/связано по меньшей мере с одним M2M приложением (например, M2M приложение (приложения) 166 на фиг. 9), или приложение может быть загружено непосредственно после начального подключения устройства (обсуждается ниже).

(iii) Предполагается, что устройство M2M услуг заранее обеспечено информацией о выбранном поставщике M2M услуг (например, имя или идентификатор SP) и соответствующим идентификатором подписки на M2M услуги. В одном варианте идентификатор подписки на M2M услуги может быть временным (например, номер контракта).

(iv) Устройство услуг M2M может быть заранее обеспечено межуровневым идентификатором M2M устройства/шлюза. Это может быть выполнено поставщиком M2M услуг посредством координации взаимодействия между поставщиком M2M услуг и оператором сети доступа, и/или каким либо иным объектом (например, изготовителем M2M устройства/шлюза), которому поставщик M2M услуг и/или оператор сети доступа доверил это.

(v) В одном варианте средства D/G-SC устройства M2M услуг могут быть предварительно обеспечены информацией о N-SC от поставщика M2M услуг, выбранного M2M объектом, и информацией о достижимости N-SC (например, имя (APN) указанных средств SP N-SC). Однако для обсуждаемого здесь технического решения по активации M2M услуг это может не потребоваться.

(vi) Предполагается, что средства D/G-SC устройства M2M услуг можно динамически аутентифицировать с помощью используемых по умолчанию средств M2M SC сети доступа 3GPP. Эта взаимная аутентификация с используемыми по умолчанию средствами N-SC сети доступа 3GPP позволяет D/G-SC предоставить используемым по умолчанию N-SC сети доступа информацию о достижимости своего поставщика услуг. Информация о достижимости может включать в себя только общедоступную информацию, которая отражает идентичность данного поставщика услуг.

РАЗДЕЛ III: ПРОФИЛЬ ПОДПИСКИ НА M2M УСЛУГИ

Заметим здесь, что обсуждение предварительного обеспечения устройства M2M услуг в основном относится к процедуре начального подключения услуг, обсуждаемой ниже. В этой связи предполагается что устройство M2M услуг заранее обеспечено идентификатором подписки на M2M услуги, который является уникальным в сети поставщика услуг. Как упоминалось ранее, в одном варианте указанный идентификатор подписки на M2M услуги может быть временным (например, номер контракта поставщика услуг, который можно использовать во время начального подключения для конфигурирования устройства M2M услуг с его постоянным идентификатором подписки на M2M услуги и межуровневым идентификатором M2M устройства/шлюза). Кроме того, предполагается, что устройство M2M услуг заранее обеспечено или способно в динамическом режиме получать (например, от соответствующего поставщика M2M услуг) учетные данные безопасности, которые можно использовать для защищенной связи с поставщиком M2M услуг и одновременно выполнить взаимную аутентификацию с сетью поставщика M2M услуг.

РАЗДЕЛ IV: ПОДКЛЮЧЕНИЯ M2M ОБЪЕКТА К СЕТИ ДОСТУПА 3GPP/3GPP2

Далее описываются некоторые базовые аспекты технического решения по активации M2M услуг (в контексте сети AN 3GPP, взятой в качестве примера) согласно конкретным вариантам настоящего изобретения. (Подробное обсуждение процедуры подключения устройства приведено ниже).

(i) Инициирование первого подключения M2M объекта (устройства/шлюза) к сети доступа, к которой адресованы используемые по умолчанию средства M2M N-SC.

(ii) Устройство услуг M2M объекта регистрируется используемыми по умолчанию средствами N-SC сети доступа на основе подписки M2M объекта на M2M услуги и сетевой архитектуры выбранного M2M объектом поставщика M2M услуг.

(iii) Обеспечение M2M объекта (как подробно обсуждается ниже, например, в разделе V), а затем информирование сети доступа о деталях межуровневых параметров, характерных для объекта, в том числе, например, о межуровневом идентификаторе M2M устройства/шлюза.

(iv) Обновление подписки на доступ для M2M объекта (например, в виде профиля подписки на доступ для объекта в сети доступа) с использованием APN постоянных средств M2M N-SC, на основе выбранного M2M объектом поставщика M2M услуг. Это может включать в себя возможное обновление соответствующей подписки на доступ в M2M объекте.

(v) Будущие постоянные подключения (к M2M SP, выбранному M2M объектом) могут быть адресованы к новому APN постоянных средств M2M N-SC, который адресует M2M объект к соответствующим средствам M2M N-SC в сети доступа или в сети поставщика услуг.

На фиг. 10 показана в качестве примера блок-схема 175, дающая общее представление о том, как M2M объект (например, M2M объект 155 на фиг. 9) подключается к выбранной (то есть выбранной объектом) сети M2M SP в техническом решении по активации 3GPP M2M услуг согласно одному варианту настоящего изобретения. В одном варианте приведенные в качестве примера различные этапы, показанные на фиг. 10 (и подробно обсуждаемые ниже со ссылками на фигуры 11-16), могут выполняться сетью доступа 3GPP. Примеры последовательностей операций обработки сообщений высокого уровня, связанные с процедурами начального и постоянного подключения, обсуждаются ниже со ссылками на фиг. 14-16. Как упоминалось выше, обсуждение в этой Части 2 фокусируется на техническом решении, касающемся активации M2M услуг, для 3GPP доступа и других доступов, которые используют ядро 3GPP EPC (например, CDMA2000 eHRPD). Как часть процедуры начального подключения (блоки 176-179 на фиг. 10) согласно одному варианту изобретения, сеть 3GPP AN принимает начальный запрос от M2M объекта на подключение к выбранной объектом сети M2M SP (блок 176). Начальный запрос может включать в себя идентификатор подписки на M2M доступ, характерный для объекта (например, IMSI и/или NAI, как упоминалось выше). В ответ (блок 177) сеть AN 3GPP может получить имя APN используемых по умолчанию средств M2M N-SC на основе AN (то есть средств N-SC, находящихся или развернутых в сети AN) независимо от любого другого имени APN, полученного от M2M объекта в качестве части начального запроса. После этого сеть доступа может подсоединить M2M объект к используемым по умолчанию средствам M2M N-SC на основе AN, используя APN используемых по умолчанию средств M2M N-SC (блок 178). Сеть 3GPP AN может затем использовать эти используемые по умолчанию средства M2M N-SC на основе AN для обеспечения начальной регистрации (на уровне M2M SL) M2M объекта в M2M SP N-SC (блок 179). Постоянное подключение (блоки 180-181 может начаться после начальной регистрации на уровне M2M SL. Как часть постоянного подключения согласно одному варианту изобретения сеть AN может установить соединение PDN 3GPP между M2M объектом и постоянными средствами M2M N-SC на основе AN, обслуживающими выбранный M2M объектом M2M SP (блок 180). Далее сеть AN стандарта 3GPP может зарегистрировать M2M объект в постоянных M2M N-SC на основе AN, используя сигнализацию на уровне M2M SL. Как упоминалось ранее, будущие постоянные подключения для M2M связи теперь могут быть адресованы к (новому) имени APN постоянных средств M2M N-SC, которое адресует M2M объект к соответствующим средствам M2M N-SC в сети доступа или сети поставщика услуг (блок 181).

Раздел V: Подробности начального подключения и последующего постоянного подключения M2M объекта к сети SP

Этот раздел раскрывает технические детали различных аспектов технического решения по активации M2M услуг 3GPP в контексте того, каким образом в конкретных вариантах настоящего изобретения выполняются начальное подключение для первого обслуживания и последующее постоянное подключение услуг M2M объекта. В подразделе V(A), приведенном ниже, подробно раскрывается аспект начального подключения, в то время как в подразделе V(В), приведенном ниже, обсуждается аспект постоянного подключения. Заметим, что термины «начальное подключение для первого обслуживания» «начальное подключение к первой сети SP», «начальное подключение», «первое начальное подключение» или термины, имеющие аналогичный смысл (как очевидно из их контекста в обсуждении) используются здесь как взаимозаменяемые для обращения к процессу, в котором новый M2M объект регистрируется в сети M2M SP первый раз (например, при первом включении питания). В общем случае указанная процедура начального подключения может выполняться только один раз в течение времени эксплуатации M2M объекта. Другими словами, как только M2M объект успешно завершает свое первое начальное подключение, могут обрабатываться последующие запросы на сетевое подключение от M2M объекта с использованием процедуры постоянного подключения, различные варианты которого описаны ниже.

Подраздел V(A): Начальное подключение M2M объекта к сети поставщика SP

НА фиг. 11 представлена примерная сетевая архитектура 190, и показано, как используются используемые по умолчанию средства M2M N-SC 192 на основе AN во время начального подключения M2M объекта к сети М2М SP согласно одному варианту технического решения по активации M2M услуг для доступов 3GPP (или других доступов, которые используют 3GPP EPC), таких как, например, CDMA2000 eHRPD). M2M объектом может быть любой из объектов 24-32 M2M связи, работающих в домене 34 M2M устройств, показанном на фиг. 1. Как упоминалось выше (например, со ссылками на фигуры 4 и 8А-8В), для облегчения обсуждения для функционально подобных сетевых элементов/компонент (например, транзитная часть, базовая сеть, AS и т.д.) используются аналогичные ссылочные позиции для универсальной конфигурации на фиг. 3 и специализированной конфигурации на основе 3GPP на фиг. 11. Таким образом, например, ссылочная позиция «84» используется для обращения к сети 3GPP доступа на фиг. 11, которую можно рассматривать как конкретную реализацию (здесь это реализация на основе 3GPP) универсальной сотовой сети 84 доступа на фиг. 3. Аналогичным образом, одна и та же ссылочная позиция «74» используется для обращения к M2M ядрам на фигурах 3 и 11 даже в том случае, когда, строго говоря, технические конфигурации этих двух M2M ядер могут отличаться (например, M2M ядро на фиг. 11 содержит используемые по умолчанию средства M2M N-SC 192, что не совпадает со случаем использования M2M ядра на фиг. 3). Аналогичный поход применим и к другим сетевым элементам (например, домен M2M устройств, транзитная часть, сеть CN, сеть SP, сервер AS и т.д.). Использование общих ссылочных позиций (в тех случаях, когда это уместно или желательно) для универсальной конфигурации 60 на фиг. 3 и примерных ее реализаций в виде конкретных конфигураций на фиг. 4, 8А-8В и 11-12 имеет своей целью просто облегчить ссылки и проиллюстрировать общее подобие архитектур на фиг. 3 и на указанных других фигурах, то есть что архитектуры на фигурах 3-4, 8А-8В и 11-12 основаны на универсальной архитектуре, показанной на фиг. 3; при этом не обязательно полагать, что архитектуры на фиг. 3-4, 8А-8В и 11-12 идентичны или виртуально подобны во всех аспектах и не имеют никаких отличий друг от друга.

Как и на других фигурах, дополнительные детали ранее обсужденных сетевых элементов/компонент здесь для краткости не повторяются. Однако следует заметить, что в конфигурации 190 на фиг. 11 сеть AN 84 3GPP разворачивает общие средства M2M SC 42 (в виде используемых по умолчанию средств M2M N-SC 192 во время начального подключения, и в виде постоянных средств M2M N-SC во время постоянного подключения), но разворачивание общих средств M2M SC 42 (фиг. 3) в сети M2M SP может быть не обязательным (как показано пунктирным блоком 194) на основе специальной конфигурации архитектуры активации M2M услуг (из числа различных конфигураций, показанных на фиг. 3), поддерживаемой поставщиком M2M SP. Таким образом, в зависимости от того, разворачивает ли поставщик M2M SP средства M2M SC 42 в своей сети, для обращения к сети M2M SP можно использовать ссылочную позицию «82» (с M2M SC) или «88» (без M2M SC) (в контексте различных конфигураций сети SP, показанных на фиг. 3). Очевидно, что термины «используемые по умолчанию средства M2M N-SC» и «постоянные средства M2M N-SC» не предполагают существование разных средств N-SC в сети AN 84; наоборот, в сети AN 84 могут быть развернуты такие же средства M2M SC (например, общие средства M2M SC 42 на фиг. 3) с разными функциональными возможностями: в виде «используемых по умолчанию» средств M2M N-SC каждый раз, когда M2M объект (например, M2M объект 155 на фиг. 9) пытается выполнить начальное подключение (например, после включения питания), и в виде «постоянных» средств M2M N-SC для последующих постоянных подключений. Таким образом, «постоянные» средства M2M N-SC могут рассматриваться как поднабор «используемых по умолчанию» средств M2M N-SC. Используемые по умолчанию средства M2M N-SC могут использоваться в качестве «используемых по умолчанию» (для обеспечения «используемых по умолчанию» функций) для всех запросов на начальное подключение, и могут иметь дополнительные функциональные возможности по отношению к «постоянным» средствам M2M N-SC, чтобы иметь возможность обработки начального подключения для всех M2M объектов. С другой стороны, «постоянные» функциональные возможности средств M2M N-SC могут быть характерными для данного M2M объекта, и могут «запускаться» (или «активироваться») для обслуживания поставщика M2M услуг, выбранного M2M объектом, во время постоянного подключения. Однако в одном варианте изобретения используемые по умолчанию функциональные возможности средств M2M N-SC и постоянные функциональные возможности M2M N-SC могут совпадать для одного M2M объекта. Кроме того, в одном варианте, где средства M2M SC 42 разворачиваются в обеих сетях (то есть в сети AN 84 3GPP (например, в виде прокси-модуля M2M SC), а также в сети 82 M2M SP (например, в виде сервера M2M SC)), общая архитектурная конфигурация на фиг. 3 может совпадать с конфигурацией, показанной на фиг. 4.

Далее описывается приведенная в качестве примера последовательность событий, детализирующих, каким образом M2M объект первый раз подключается (здесь это называется «начальное подключение» или «первое начальное подключение», упомянутое ранее) к сети 82 (или 88) M2M SP согласно одному варианту настоящего изобретения. В других вариантах последовательность этапов, приведенная ниже, может быть выполнена в другом порядке.

(1) Как упоминалось в разделе 1 (Часть 2), устройство M2M доступа (например, устройство 162 M2M доступа на фиг. 9) может быть заранее сконфигурировано с идентификатором подписки на сетевой доступ (который может идентифицировать подписку на M2M доступ для соответствующего M2M объекта 155).

(2) Идентификатор подписки на M2M доступ может указывать на подписку M2M объекта, которая может содержать APN используемых по умолчанию средств M2M N-SC на основе AN (фиг. 1), что также упоминалось выше в разделе I (Часть 2). Устройство M2M доступа может быть заранее сконфигурировано с APN используемых по умолчанию средств AN N-SC либо может быть сконфигурировано без указанного APN.

(3) После приема запроса от M2M объекта (который может быть послан с использованием устройства M2M доступа объекта) для начального подключения для первого обслуживания сеть 84 3GPP (фиг. 11) может использовать APN используемых по умолчанию средств M2M N-SC сети доступа для установления соединения с платформой 192 используемых по умолчанию средств M2M N-SC сети доступа. Другими словами, независимо от APN, которое M2M объект может обеспечить во время попытки первого подключения, сеть AN 84 3GPP может переписать это обеспеченное объектом имя (APN) на APN используемых по умолчанию средств M2M N-SC сети AN, которое сконфигурировано как часть подписки на M2M доступ для M2M объекта, хранящейся в сети AN 84 3GPP. [В одном варианте сеть AN 84 3GPP может распознать первое начальное подключение, когда подписка на M2M доступ на основе AN не содержит какого-либо APN, отличного от APN используемых по умолчанию средств M2M N-SC сети доступа].

(4) Когда M2M объект подсоединяется к используемым по умолчанию средствам M2M N-SC 192 сети доступа (например, используя устройство M2M доступа объекта), он может представить (например, используя устройство M2M услуг объекта) идентификатор подписки на M2M услуги (упомянутый в разделах II и III в Части 2) в сеть AN 84 3GPP. Этот идентификатор подписки на услуги помогает используемым по умолчанию средствам M2M N-SC 192 сети AN идентифицировать поставщика M2M услуг, выбранного M2M объектом, а затем также идентифицировать (на основе соглашения об уровнях обслуживания (SLA)) архитектуру для активации M2M услуг, которая поддерживается сетью поставщика M2M SP, выбранного объектом, в соответствии с общими средствами M2M N-SC (или M2M SC) 42 на фиг. 3 (например, независимо от того, реализует ли сеть поставщика SP архитектуру для активации M2M услуг, совместимую или не совместимую с ETSI и независимо от того, развернула или нет сеть SP свои средства M2M N-SC и т.д.).

(5) Используемые по умолчанию средства M2M N-SC 192 сети доступа могут выполнять начальную регистрацию на уровне M2M SL (для M2M объекта 155) на основе соответствующей архитектуры для активации соответствующих услуг поставщика M2M SP и может осуществлять связь со средствами M2M SP N-SC 194 (если они имаются) для следующего: (а) конфигурирования и распределения шлюза; (b) конфигурирования, распределения и регистрации идентификатора средств D/G-SC; (c) идентификации возможных идентификаторов M2M приложений, поддерживаемых устройством 163 M2M услуг (фиг. 9), которое использует устройство 162 M2M доступа (фиг. 9), осуществляющего в данный момент связь с сетью AN 84 3GPP; (d) всех других необходимых межуровневых параметров. (Следует заметить, что, хотя в данном описании в качестве примера межуровневого параметра используется внешний идентификатор M2M D/G, настоящее изобретение предполагает возможность использования других межуровневых параметров (если это необходимо), которые в будущем могут быть точно определены в спецификациях 3GPP, 3GPP2 или других сотовых спецификациях).

В варианте, в котором M2M SP не разворачивает средства M2M SP N-SC (например, в варианте, показанном на фиг. 12), используемые по умолчанию средства M2M N-SC сети AN все же могут получать вышеупомянутую информацию, как обсуждается ниже в связи со случаем 1 в разделе VI.

(6) После вышеописанного этапа (5) или одновременно с ним средства M2M N-SC 192 могут обновить подписку для устройства M2M доступа (то есть подписку на M2M доступ для устройства 162 M2M доступа в M2M объекте 155) в домашней сети доступа (то есть в 3GPP AN 84). Эта подписка на M2M доступ, характерная для объекта, может находиться, например, на домашнем абонентском сервере (HSS) (на фиг. 11 не показан, но показан на фиг. 12) и может быть там обновлена с использованием следующей информации: (а) межуровневого идентификатора M2M D/G; (b) имени (APN) средств M2M N-SC (для сигнализации на уровне SL и данных для соответствующих средств M2M N-SC). Это APN может относиться к постоянным средствам M2M N-SC сети AN (например, M2M N-SC 198 на фиг. 12), которые связаны с M2M SP или которые определенным образом обслуживают M2M SP, выбранный M2M объектом, и которые должны использоваться во время «постоянного подключения» (описанного ниже); (с) другой соответствующей и необходимой информации для поддержки M2M связи от M2M объекта 155.

Данный этап (6) также может включать в себя динамическое обновление (с помощью используемых по умолчанию средств M2M N-SC) подписки на M2M доступ на M2M объекте с использованием той же самой информации.

(7) Вдобавок, используемые по умолчанию средства M2M N-SC 192 сети AN могут осуществлять связь с архивом профиля абонента (SPR) (не показан) на сервере HSS сети AN для обновления подписки на политику M2M доступа (также называемую «подпиской на M2M доступ») с соответствующим качеством обслуживания (QoS), которая потребуется для поддержания приложений 166 M2M услуг, работающих под управлением устройства 163 M2M услуг (фиг. 9). Аналогичным образом, сеть M2M SP также может быть обновлена с использованием аналогичной информации (например, могут быть обновлены M2M SP N-SC 194, если они развернуты).

Подраздел V(B): Последующее постоянное подключение M2M объекта

После выполнения начального подключения для первого обслуживания (как обсуждалось в подразделе V(A)) и обеспечения M2M объекта всеми необходимыми параметрами, относящимися к подписке на M2M доступ, межуровневыми и всеми другими параметрами, M2M объект может перезагрузиться или вновь подключиться к сети выбранного SP с учетом всех имевших место изменений. В одном варианте это означает, что M2M объект может выполнить постоянное подключение (как часть перезагрузки или повторного подключения), как это определено ниже.

На фиг. 12 в качестве примера показана сетевая архитектура 196, иллюстрирующая использование постоянных средств M2M N-SC 198 на основе AN во время постоянного подключения M2M объекта (например, M2M объекта 155 на фиг. 9) к сети 88 поставщика M2M SP согласно одному варианту технического решения по активации M2M услуг в соответствии с основополагающими принципами настоящего изобретения. В варианте на фиг. 12 средства M2M N-SC (то есть общие средства M2M SC 42 в контексте универсальной архитектуры на фиг. 3) находятся только в сети 3GPP AN 84 (то есть в виде сервера M2M N-SC). Хотя фигуры 8А-8В относятся к сети 150 поставщика SP (не ETSI), для элементов сети AN (3GPP) на фигурах 8А-8В и 12 для облегчения обсуждения и для обозначения одинаковых/подобных элементов сети доступа на этих фигурах используются одинаковые ссылочные позиции. Однако на фиг. 12 в качестве части базовой сети 78 3GPP дополнительно показан объект 200 управления мобильностью (MME) для предоставления контекста для различных потоков сообщений, обсуждаемых ниже со ссылками на фигуры 14-16. Как и ранее, обсуждение описанных сетевых компонент/элементов здесь для краткости не повторяется. Прежде чем продолжать обсуждение механизма постоянного подключения следует подчеркнуть, что для обращения к используемым по умолчанию средствам M2M N-SC сети AN и постоянным средствам M2M N-SC для краткости используются разные ссылочные позиции «192» и «198» соответственно. Как упоминалось ранее, термины «используемые по умолчанию» средства M2M N-SC сети AN и «постоянные» средства M2M N-SC сети AN относятся к разным функциональным возможностям одних и тех же средств N-SC; при этом используемые по умолчанию M2M N-SC 192 используются для начального подключения сети SP (например, пока не будет получен идентификатор M2M SP, выбранного M2M объектом, известный сети AN 3GPP) и для постоянных средства M2M N-SC 198 (которые связаны с M2M SP или которые специфическим образом обслуживают M2M SP, идентифицированный M2M объектом, например, во время начального подключения), используемые для последующего постоянного подключения к сети SP. Кроме того, независимо от того, развернуты ли средства M2M N-SC в виде прокси-модуля или сервера в сети AN 3GPP, такой прокси-модуль/сервер средств M2M N-SC может быть подходящим образом сконфигурирован для реализации функциональных возможностей используемых по умолчанию средств M2M N-SC и/или постоянных средств M2M N-SC.

Далее в качестве примера описывается последовательность событий, подробно раскрывающих то, каким образом M2M объект выполняет постоянное подключение к выбранной сети M2M SP (здесь это сеть 88 поставщика услуг на фиг. 12) согласно одному варианту настоящего изобретения. В других вариантах эта последовательность этапов может выполняться в другом порядке.

(1) В качестве части постоянного подключения устройство M2M доступа (например, устройство 162 M2M доступа в M2M объекте 155 на фиг. 9) может использовать N-SC APN (то есть имя (APN) постоянных средств M2M N-SC 198 на основе AN, которые могут функционировать в качестве сервера средств M2M N-SC сети AN в одном варианте изобретения), который был предоставлен (например, как часть обновления подписки на M2M доступ, находящейся в M2M объекте) во время начального подключения для первого обслуживания. Однако в том случае, если M2M объект каким либо путем не был сконфигурирован с этим APN (постоянных средств M2M N-SC сети AN), его устройство M2M доступа может использовать нулевое имя (NULL) APN. Устройство M2M доступа может соответствовать всем деталям соответствующего протокола 3GPP для установления соединения сети пакетной передачи данных (PDN) 3GPP c M2M N-SC 198 (фиг. 12).

(2) M2M объект (например, через свое устройство M2M доступа) может использовать сигнализацию уровня M2M SL для регистрации в M2M N-SC 198 на основе AN, которые выступают в качестве SP 88, выбранного M2M объектом. Затем сеть AN 3GPP может адресовать будущие передачи (в том числе, будущие запросы на постоянные подключения) от M2M объекта на APN этих постоянных средств M2M N-SC 198, устанавливая тем самым постоянное подключение M2M объекта к SP 88, выбранному M2M объектом. На фиг. 12 имя APN для сигнализации на уровне SL может относиться к средствам M2M N-SC 198 на основе AN. Таким образом, сигнализация на уровне SL от M2M объекта (не показанного на фиг. 12) в домене 34 M2M устройств на M2M N-SC 198 на основе AN показана двунаправленной пунктирной стрелкой 202 и блоком 203. С другой стороны, APN передачи данных на уровне SL может относиться к серверу AS 62 на основе SP. Таким образом, на фиг. 12 последовательная пересылка данных уровня SL между M2M объектом и его M2M SP 88 (к которому M2M объект теперь подключен) через постоянные средства M2M N-SC 198 на основе AN показана с использованием двунаправленной стрелки 205 и блока 206.

В разделе VI, представленном ниже, описывается, как различные опции архитектуры для активации M2M услуг работают согласно различным вариантам настоящего изобретения.

(3) Во время регистрации M2M объекта в выделенных N-SC (то есть M2M N-SC 198) согласно APN средств N-SC, M2M объект может обеспечить (например, через свое устройство M2M доступа) свой межуровневый идентификатор для M2M D/G, который можно использовать на уровне услуг и транспортном уровне для идентификации M2M объекта и его достижимости все время, пока средства M2M D/G-SC зарегистрированы в постоянных средствах M2M N-SC 198 сети AN. Очевидно, что в одном варианте, если M2M объект не зарегистрирован в сети AN, сеть M2M SP не сможет предоставить ему M2M услуги.

(4) В одном варианте в результате выполнения вышеупомянутой процедуры начального подключения постоянные средства M2M N-SC 198 сети AN могут иметь доступ к межуровневому идентификатору M2M устройства/шлюза, а также могут отобразить этот межуровневый идентификатор для M2M D/G на один или несколько следующих параметров, которые относятся к устройству M2M доступа (например, устройству 162 доступа на фиг. 9) и/или устройству M2M услуг (например, устройству 163 услуг на фиг. 9):

(а) идентификатор подписки на доступ к M2M D/G (например, IMSI и/или NAI);

(b) транспортный адрес M2M устройства/шлюза, которым может быть, например, адрес версии 6 (IPv6) Протокола Интернет (IP), префикс сети IPv6, адрес IPv4, адрес IPv4 вместе с номером порта и т.д.;

(с) транспортный адрес с коммутацией каналов (CS) для M2M устройства/шлюза, например, номер ISDN мобильного абонента (MSISDN) (где «ISDN» относится к «Цифровой сети интегральных услуг»), номер мобильной директории (MDN) и т.д. Это возможно, если M2M устройство/шлюз поддерживает CS доступ через службу коротких сообщений (SMS); и

(d) любой другой подходящий параметр, выбранный/необходимый оператору сети AN 3GPP для технического решения по активации M2M услуг (3GPP) согласно конкретным вариантам настоящего изобретения.

Раздел VI: Приведенные в качестве примера варианты архитектуры для технического решения по активации M2M услуг (3GPP)

На фиг. 13 представлены приведенные в качестве примера варианты архитектуры для активации M2M услуг для сети AN 3GPP (например, 3GPP версии сети AN 84 или 86 по фиг. 3). Фиг. 13 является упрощенной иллюстрацией, используемой для ссылок при обсуждении каждого случая, подробно описанного ниже. Как показано в блоке 212 на фиг. 13, варианты архитектуры можно разделить на две большие категории в зависимости от того, развернуты или нет общие средства M2M SC (в виде прокси-модуля и/или сервера N-SC) в сети AN (3GPP). Если в сети AN (3GPP) имеются средства M2M N-SC, то тогда два случая 214-215 относятся к ситуации, когда оператор сети AN (3GPP) имеет соглашение об использования уровня услуг (SLA) с поставщиком M2M услуг (SP): случай 1 (блок 214) относится к ситуации, в которой средства M2M SC развернуты только в сети AN (3GPP) в виде сервера M2M средств N-SC, в то время как M2M SP развернул сервер M2M AS 62; в случае 2 (блок 215) средства M2M N-SC развернуты в сети AN (3GPP) в виде прокси-модуля M2M N-SC, в то время как M2M SP разворачивает соответствующий сервер M2M N-SC, то есть и сеть AN (3GPP) и M2M SP разворачивают средства M2M SC (например, общие M2M SC 42, показанные на фиг. 3). С другой стороны, случай 3 (блок 217) относится к ситуации, когда сеть AN (3GPP) имеет SLA с поставщиком M2M SP (который разворачивает средства M2M SC в виде сервера M2M N-SC) но при этом прокси-модуль M2M N-SC в сети AN (3GPP) не допускается.

Заметим, что обсуждение в разделе V (включая подразделы V(А) и V(B)) в Части 2 предполагает, что средства M2M N-SC принадлежат оператору 84 3GPP AN и выполняют функции сервера и/или прокси-модуля M2M N-SC. Например, в варианте по фиг. 11 используемые по умолчанию средства M2M N-SC 192 могут функционировать в качестве прокси-модуля M2M N-SC, когда поставщик M2M SP также разворачивает средства M2M N-SC в виде сервера 194. С другой стороны, в варианте на фиг. 12 постоянные средства M2M N-SC 198 могут функционировать в качестве сервера средств N-SC. Как упоминалось ранее со ссылками на фиг. 7, когда средства M2M SC разворачиваются в сети AN (3GPP), средства M2M SC могут быть развернуты либо в виде сервера M2M N-SC, либо в виде прокси-модуля M2M N-SC, либо и то и другое (в качестве сервера M2M N-SC для одного поставщика услуг и в качестве прокси-модуля M2M N-SC для другого поставщика услуг). Таким образом, в обсуждении в разделе V сеть AN 84 (3GPP) может иметь межуровневую информацию для динамического доступа зарегистрированного устройства M2M услуг (например, устройство 163 услуг M2M объекта 155 на фиг. 9), которое использует соответствующее устройство M2M доступа (например, устройство 162 доступа на фиг. 9), использующее подписку на доступ (M2M объекта 155), относящуюся к оператору сети AN (3GGP). Однако, как обсуждалось в Части 1, имеется ряд архитектурных опций, в которых используются различные варианты разворачивания средств M2M N-SC и которые зависят от того, имеется или нет соглашение SLA между оператором AN 3GPP и выбранным поставщиком M2M SP. Исходя из этих различных возможных вариантов разворачивания, данный раздел VI относится к тем возможным вариантам архитектуры активации M2M услуг, в которых используется сеть доступа 3GPP в предположении, что между сетью AN 3GPP и поставщиком M2M услуг существует соглашение (SLA). Далее подробно описывается каждый из случаев, показанных на фиг. 13.

Случай 1: В этом случае (блок 214, фиг. 13) между оператором AN 3GPP и поставщиком M2M SP, выбранным M2M объектом, существует соглашение (SLA), сервер средств M2M N-SC развернут в сети AN (3GPP), и M2M SP разворачивает сервер M2M AS. По своей архитектуре этот случай подобен конфигурации 196 на фиг. 12.

(А) Начальное подключение для первого обслуживания: В этом случае во время начального подключения M2M объекта сервер средств M2M N-SC на основе AN (которые могут функционировать в качестве используемых по умолчанию средств M2M N-SC 192 сети AN, как это обсуждалось со ссылками на фиг. 11), может осуществлять связь с M2M SP (например, M2M SP 88 на фигурах 11=12), используя интерфейс API уровня M2M SL для передачи всей информации, относящейся к межуровневому идентификатору M2M D/G, другой информации, которая может быть необходима поставщику M2M SP (например, идентификатор подписки на M2M услуги) и другой информации, которая может относиться к устройству M2M услуг (в M2M объекте) такой как, например, идентификатор M2M средств D/G-SC, и информацию о том, необходимо ли его динамическое конфигурирование, и т.д. В целом, механизм начального подключения в случае 1 очень похож на детали и сценарий, описанные в подразделе V(А) (в Части 2), и поэтому описание указанных деталей здесь для краткости не повторяется.

(B) Последующее постоянное подключение: Постоянное подключение согласно случаю 1 может быть точно таким, как описано в подразделе V(B) (в Части 2), и поэтому указанные детали здесь для краткости не повторяются.

Случай 2: В этом случае (блок 215, фиг. 13) между оператором сети AN 3GPP и поставщиком M2M SP, выбранным M2M объектом, существует соглашение (SLA), сервер средств M2M N-SC развернут в M2M SP (M2M N-SC 194 на фиг. 11, развернутые в виде сервера N-SC), и сеть AN (3GPP) разворачивает прокси-модуль средств M2M N-SC (например, используемые по умолчанию средства M2M N-SC 192 на фиг. 11, функционирующих в качестве прокси-модуля N-SC). По своей архитектуре этот случай подобен конфигурации 95 на фиг. 4.

(А) Начальное подключение для первого обслуживания: В целом, механизм начального подключения в этом случае очень похож на детали и сценарий, описанные в подразделе V(A), приведенном выше, и поэтому здесь дается только краткое описание некоторых дополнительных аспектов. В этом случае используемые по умолчанию средства M2M N-SC сети AN (3GPP) могут совпадать с используемыми по умолчанию средствами M2M N-SC 192 на фиг. 11, но могут выполнять функции прокси-модуля средств M2M N-SC (в сети AN (3GPP)). Во время начального подключения M2M объекта прокси-модуль средств M2M N-SC на основе AN может осуществлять связь с сервером средств M2M SP N-SC (например, с сервером 194 средств M2M N-SC на фиг. 11), используя интерфейс API уровня M2M SL для передачи всех сигнальных сообщений уровня SL, сохраняя возможность приема или перехвата всей межуровневой информации для M2M устройства/шлюза, как это было описано выше в подразделе V(A). После начальной регистрации (во время начального подключения для первого обслуживания) может быть выполнено обновление подписки устройства M2M доступа с помощью имени APN средств M2M N-SC, которое в этом случае может относиться к M2M N-SC 194 поставщика M2M SP (фиг. 11) в качестве сервера средств N-SC. В одном варианте также возможно обратиться к прокси-модулю средств N-SC в сети 3GPP доступа, который предоставляет сигнальную информацию на сервер M2M N-SC в сети поставщика услуг (SP).

(В) Последующее постоянное подключение: Постоянное подключение согласно этому случаю 2 может точно совпадать с подключением, описанным в приведенном выше подразделе V(B) за исключением того, что средства M2M N-SC в сети AN (3GPP) функционируют теперь в качестве прокси-модуля средств M2M N-SC. Другими словами, прокси-модуль M2M средств N-SC в сети AN (3GPP) в этом случае выполняет те же самые функции, что и сервер средств M2M N-SC, обсужденные выше в подразделе V(B).

Случай 3: В этом случае (блок 217, фиг. 13) между оператором сети AN (3GPP) и M2M SP, выбранным M2M объектом, существует соглашение (SLA), и в M2M SP развернут сервер M2M N-SC (например, M2M N-SC 194 на фиг. 11, развернутый в виде сервера N-SC), но при этом прокси-модуль средств M2M N-SC сети AN (3GPP) может быть не разрешен (то есть M2M SP N-SC 194 может не иметь доступ (или авторизацию) к использованию функциональных возможностей прокси-модуля, которые могут поддерживаться, например, используемыми по умолчанию средствами M2M N-SC сети AN). С точки зрения архитектуры этот случай может быть подобен опции 1, обсужденной ранее со ссылками на фиг. 3.

(А) Начальное подключение для первого обслуживания: После того, как используемые по умолчанию средства M2M N-SC сети AN идентифицировали, что соглашение M2M SP SLA указывает, что сети SP разрешено иметь сервер M2M N-SC в сети SP, но не разрешено использовать прокси-модуль средств M2M N-SC внутри сети 3GPP доступа (то есть используемые по умолчанию средства M2M N-SC сети AN не могут функционировать в виде прокси-модуля, как в случае 2, обсужденном выше), используемые по умолчанию средства M2M N-SC сети AN могут выполнять одну из следующих двух опций:

(i) Опция 1: В этой опции используемые по умолчанию средства M2M N-SC сети AN могут предоставить средства D/G-SC (M2M объекта) (например, средства M2M SC, характерные для объекта, которые показаны на фиг. 9), идентификатор N-SC поставщика услуг и/или информацию о достижимости, и дать команду средствам D/G-SC о необходимости провести обновление используемых по умолчанию средств M2M N-SC сети доступа с использованием необходимой (межуровневой) информации после успешного завершения начальной регистрации в SP N-SC (которые развернуты в виде сервера N-SC, как упоминалось ранее). Таким образом, вместо получения указанных межуровневых параметров и другой информации от M2M SP N-SC (как обсуждалось выше в подразделе V(A)) в этой опции используемые по умолчанию средства M2M N-SC сети AN могут получить необходимую информацию от D/G-SC.

После завершения M2M объектом процедуры регистрации начального подключения средства D/G-SC могут выполнить обновление начальной регистрации на уровне SL с помощью используемых по умолчанию средств M2M N-SC сети доступа. На этом этапе средства D/G-SC могут предоставить необходимую (межуровневую) информацию используемым по умолчанию средствам M2M N-SC сети доступа для выполнения обновления подписки на M2M доступ (MASU). Обновление MASU может включат в себя обновление используемых по умолчанию средств M2M N-SC сети AN, например, (домашней), сети AN (3GPP) c помощью постоянных средств M2M N-SC сети AN, которые указывают необходимый P-GW, который будет обеспечивать M2M сигнализацию и обслуживать трафик данных между данным M2M объектом и его поставщиком M2M услуг.

После успешного выполнения обновления подписки на M2M доступ используемые по умолчанию средства M2M N-SC сети доступа могут сообщить D/G-SC об успешном обновлении и обновить подписку на доступ M2M устройства/шлюза на M2M устройстве/шлюзе, если это возможно (как упоминалось выше в подразделе V(A).

(ii) Опция 2: В этой опции используемые по умолчанию средства M2M N-SC сети доступа могут предоставить D/G-SC (M2M объекта) идентификатор N-SC поставщика услуг и/или информацию о достижимости, как в опции 1 (смотри случай 3) и также может обеспечить индикацию для средств SP N-SC (которые развернуты в виде сервера N-SC как упоминалось выше) для обновления используемых по умолчанию средств N-SC сети доступа (с использованием необходимой межуровневой информации) после завершения этапов первой начальной регистрации услуг, но перед тем, как SP N-SC послали на D/G-SC сообщение о том, что начальная регистрация прошла успешно.

В одном варианте средства SP N-SC могут инициировать сессию для обновления используемых по умолчанию средств M2M N-SC сети доступа с использованием необходимой информации на основе начального подключения для первого обслуживания устройства M2M услуг M2M объекта.

Затем используемые по умолчанию средства M2M N-SC сети доступа могут выполнить процедуру MASU, обсужденную выше. После успешного выполнения процедуры MASU используемые по умолчанию средства M2M N-SC сети доступа могут сообщить SP N-SC об успешном выполнении (а не D/G-SP, как в опции 1, обсужденной выше). Затем средства SP N-SC могут сообщить соответствующим средствам D/G-SC об успешной начальной регистрации.

(B) Последующее постоянное подключение: Процедура постоянного подключения в случае 3 может точно совпадать с процедурой, описанной выше в подразделе V(B) за исключением того, что сервер средств M2M N-SC представляет собой N-SC внутри сети SP, и M2M N-SC внутри сети 3GPP доступа (если она имеется) не разрешаются (то есть средства M2M SP N-SC 194 могут не иметь доступ (или авторизацию) на использование функциональных возможностей прокси-модуля в сети AN, как упоминалось ранее).

Здесь имя APN, которое обеспечивается или обновляется на основе, например, процедуры MASU во время начального подключения для первого обслуживания, может указать шлюз P-GW, который связан с сетью SP. Таким образом, когда соединение PDN установлено, P-GW может получить профиль подписки на доступ к M2M устройству/шлюзу, который включает в себя межуровневый идентификатор M2M D/G и другие параметры, которые необходимы для межуровневого взаимодействия с M2M N-SC сервером сети SP.

Раздел VII: Приведенные в качестве примера последовательности операций по обработке вызовов высокого уровня

На фигурах 14-16 представлены примеры последовательностей операций по обработке вызова высокого уровня для начального подключения для первого обслуживания M2M объекта и последующего постоянного подключения к поставщику M2M услуг, выбранному объектом, с использованием сети 3GPP доступа согласно техническому решению по активации M2M услуг (MSES) в соответствии с конкретными вариантами настоящего изобретения. В примерах, показанных на фигурах 14-16, предполагается, что устройство M2M доступа (например, устройство 162 доступа в M2M объекте 155 по фиг. 9) имеет действующую подписку в сети AN (3GPP) с использованием «IMSI1» в качестве IMSI, распределенного для этого устройства M2M доступа. Также предполагается, что оператор сети AN (3GPP) имеет профиль подписки на M2M доступ для устройства M2M доступа на основе «IMSI1», распределенного для этого устройства. Этот профиль подписки на начальный доступ имеет имя APN используемых по умолчанию средств M2M N-SC сети AN, сконфигурированное (по меньшей мере для способствования начальному подключению к сети SP) вместе с другими параметрами согласно политики оператора домашней сети AN. В связи с подробным обсуждением процедур начального и постоянного подключения (в разделах V и VI Части 2), фигуры 14-16 обсуждаются ниже довольно кратко. Заметим, что разные последовательности этапов, показанных на фигурах 14-16, являются по сути лишь примерами. В некоторых других вариантах осуществления изобретения эти последовательности могут быть изменены, модифицированы или переупорядочены согласно конкретным требованиям к реализации.

На фиг. 14 в качестве примера показаны последовательности операций по обработке вызова высокого уровня согласно одному варианту настоящего изобретения для начального подключения M2M объекта (например, M2M объекта 155 на фиг. 9) к выбранному M2M SP (например, M2M SP 82 на фиг. 11) через сеть AN (3GPP) (например, сеть AN 84 (3GPP) на фиг. 11). Заметим, что из-за разворачивания средств N-SC в сети SP на фигурах 14-16, можно считать, что эти фигуры представляют архитектуру для активации M2M услуг, показанную на фиг. 11. Однако подробности базовой сети 88 (3GPP) на фиг. 11 представлены на фиг. 12, где показаны различные компоненты/элементы (например, MME, PCRF и т.д.) базовой сети 78. Таким образом, для удобства обсуждения фигуры 14-16 можно интерпретировать как «комбинацию» фигур 11 и 12, с тем чтобы для идентификации компонент/элементов на фигурах 14-16, имеющих одинаковые или подобные функциональные возможности, можно было использовать одинаковые ссылочные позиции, взятые из фигур 11-12. За исключением узла eNB 219 и обслуживающего шлюза (SGW) 145 на фигурах 14-16, все другие компоненты сети AN на фигурах 14-16 показаны на фиг. 12. Как следует из предшествующего обсуждения, узел eNB 219 может представлять собой любую из базовых станций 70-72, которая обеспечивает интерфейс беспроводной связи с M2M объектом 155, действующим в домене 34 M2M устройств. С другой стороны, для удобства обсуждения одна и та же ссылочная позиция «145» используется для обращения к SGW на фигурах 14-16 и HSGW (версия на основе eHRPD) по фиг. 12 по причине их большого сходства и одинакового назначения.

Обратимся теперь к фиг. 14, где после начального включения питания (блок 220) устройство доступа M2M объекта (например, устройство 162 доступа на фиг. 9) может послать запрос на начальное подключение на MME 200 сети AN (3GPP), как показано на этапе 221. Этот запрос на начальное подключение может включать в себя IMSI устройства 162 доступа (здесь это «IMSI1», как упоминалось ранее). В варианте по фиг. 14 устройство 162 доступа предварительно не сконфигурировано с используемыми по умолчанию средствами M2M N-SC сети AN. Таким образом, запрос на начальное подключение на этапе 221 не содержит APN (например, этот запрос может быть послан с нулевым значением APN). Получив запрос на начальное подключение MME 200 может выбрать свой профиль подписки устройства M2M доступа (то есть профиль подписки на M2M доступ, обсужденный в разделе I Части 2) и другую подходящую информацию (например, ключи аутентификации устройства) из HSS 142 на основе IMSI1, распределенного для этого устройства, как показано на этапе 222. MME 200 принимает APN используемых по умолчанию средств M2M N-SC 192 сети AN как часть упомянутого профиля подписки сети AN. Устройство 162 доступа может ожидать аутентификацию доступа (блок 223), пока MME 200 использует APN используемых по умолчанию средств M2M N-SC сети AN для создания сессии для соответствующего шлюза SGW 145 и соответствующего шлюза P-GW 147, как показано на этапах 224-225. После создания необходимых сессий для SGW и P-GW объект MME 200 может сообщить об успешном подключении AN устройству доступа, а также выделить ему IP адрес на этапе 226. Затем M2M объект 155 может попытаться установить PDN соединение с используемыми по умолчанию средствами M2M N-SC 192 сети AN (блок 227) через PGW 147 (блок 228). В данном варианте (фиг. 14) устройство доступа может установить соединение для сигнализации на уровне M2M SL (блок 229) с используемыми по умолчанию средствами M2M N-SC 192 сети AN для обеспечения сигнализации на уровне M2M SL (например, для устройства 163 на фиг. 9) для начальной регистрации M2M объекта у выбранного поставщика M2M SP 82 (блок 230). Затем устройство доступа M2M объекта 155 может послать запрос на начальную (SL) регистрацию на используемые по умолчанию средства N-SC 192 на этапе 231. Этот запрос может включать в себя идентификатор подписки на M2M услуги M2M объекта и возможно идентификатор средств D/G-SC (в зависимости от того, является ли M2M объект 155 M2M устройством или M2M шлюзом). Идентификатор подписки на M2M услуги помогает используемым по умолчанию средствам M2M N-SC 192 сети AN идентифицировать M2M SP 82, выбранный M2M объектом, и соответствующий SLA между оператором сети AN (3GPP) и M2M SP, а также идентифицировать архитектуру для активации M2M услуг, поддерживаемую сетью M2M SP, на основе SLA (блок 232). Затем используемые по умолчанию средства M2M N-SC 192 сети AN могут запросить начальную регистрацию M2M объекта 155 на уровне SL в выбранном M2M SP 82 (этап 233). На этапе 233 используемые по умолчанию средства N-SC 192 сети AN могут предоставить идентификатор подписки на M2M услуги для M2M объекта и идентификатор D/G-SC средствам M2M SP N-SC 194 (которые могут быть развернуты в виде сервера M2M SP N-SC), и могут запросить межуровневый идентификатор M2M D/G и другие параметры из M2M SP N-SC 194. После распределения сетью 82 поставщика SP необходимого межуровневого идентификатора M2M D/G (блок 234), средства M2M SP N-SC 194 могут подтвердить получение запроса на начальную регистрацию на уровне SL (на этапе 233) и могут предоставить необходимый межуровневый ID используемым по умолчанию средствам M2M N-SC сети AN на этапе 235. В ответ, на этапе 236 используемые по умолчанию средства N-SC 192 сети AN могут обновить профиль подписки сети AN устройства M2M доступа на сервере HSS 142 с использованием упомянутого межуровневого идентификатора D/G и возможно с использованием APN соответствующих постоянных средств M2M N-SC на основе AN для обеспечения в будущем постоянного подключения M2M объекта 155 к выбранному M2M SP 82. Как упоминалось ранее, в одном варианте используемые по умолчанию средства M2M N-SC могут также функционировать в качестве постоянных средств M2M N-SC для данного M2M объекта и выбранного им M2M SP. На этапе 237 используемые по умолчанию средства M2M N-SC 192 сети AN подтверждают успешность начального подключения, а также выделяют для M2M объекта 155 имя APN постоянных средств M2M N-SC для постоянного подключения в будущем. Затем M2M объект 135 может выполнить постоянное подключение сети SP (блок 238), как обсуждается ниже со ссылками на фигуры 15-16.

На фиг. 15 в качестве примера показаны последовательности выполнения операций по обработке вызова высокого уровня согласно одному варианту настоящего изобретения для постоянного подключения M2M объекта (например, M2M объекта 155 на фиг. 9) к выбранному M2M SP (например, M2M SP 82 на фиг. 11) через сеть AN 3GPP (например, сеть AN 84 3GPP на фиг. 11). Последовательности обработки вызова на фиг. 15 относятся к случаю 2(В), описанному выше в разделе VI (в части 2 настоящего изобретения) и относится к архитектуре для активации M2M услуг, подобной архитектуре 190 на фиг. 11 (то есть сеть AN разворачивает свои средства M2M N-SC в виде прокси-модуля 192 средств N-SC, в то время как сеть SP разворачивает свои средства N-SC в виде сервера 194 средств N-SC). Поскольку используемые по умолчанию средства M2M N-SC 192 сети AN на фиг. 11 могут быть сконфигурированы для выполнения в виде прокси-модуля средств M2M N-SC на основе AN, в обсуждаемом случае для прокси-модуля средств N-SC, показанного на фиг. 15, и для используемых по умолчанию средств M2M N-SC сети AN, показанных на фиг. 11, используется одинаковая ссылочная позиция «192». Как упоминалось ранее, при разворачивании общих средств M2M SC 42 в универсальной архитектуре по фиг. 3 в сети AN 3GPP, указанные средства M2M SC могут быть развернуты в виде используемых по умолчанию/постоянных средств M2M N-SC на основе AN, которые могут, в свою очередь, реализовать функциональные возможности сервера средств N-SC или прокси-модуля средств N-SC, в зависимости от архитектурной конфигурации. Таким образом, для облегчения обсуждения на фигурах 14-16 для идентификации всех указанных развернутых средств N-SC на основе AN используется общая ссылочная позиция «192».

Обратимся теперь к фиг. 15, где после успешного завершения начального подключения (блок 240) устройство M2M доступа в M2M объекте 155 может на этапе 241 запросить постоянное подключение, используя имя APN средств N-SC, которое было предоставлено во время начального подключения для первого обслуживания (то есть на этапе 237 по фиг. 14). Как упоминалось ранее, на этапе 241 APN средств N-SC может относиться к постоянным средствам M2M N-SC сети AN (здесь это прокси-модуль 192 средств M2M N-SC сети AN), обслуживающий поставщика 82 M2M, выбранного M2M объектом. (Однако, в других вариантах имя APN средств N-SC на этапе 241 может относиться к M2M N-SC поставщика SP в виде сервера 194 N-SC, как обсуждалось в случае 2, описанном выше в разделе VI. Объект MME 200 может затем установить связь с сервером HSS 142 для выборки профиля подписки AN устройства M2M доступа (и другой необходимой информации) из HSS 142 на этапе 242. Поскольку сервер HSS имеет имена как используемых по умолчанию, так и постоянных средств M2M N-SC, объект MME делает заключение, что данное подключение является постоянным подключением. Следующие этапы 243-245 в контексте APN прокси-модуля N-SC на фиг. 15 по существу подобны этапам 224-226 в контексте APN используемых по умолчанию N-SC на фиг. 14, и поэтому они подробно здесь не описываются. Затем M2M объект 155 пытается установить PDN соединение с сервером 194 средств N-SC выбранного SP (блок 246) через P-GW 147 и прокси-модуль 192 средств N-SC (блок 247). Устройство доступа M2M объекта может установить соединение для сигнализации на уровне M2M SL (блок 248) с помощью прокси-модуля 192 средств M2M N-SC сети AN для обеспечения сигнализации уровня M2M SL устройством услуг (например, устройством 163 услуг на фиг. 9) для постоянной регистрации M2M объекта у поставщика 82 (M2M SP) (блок 249). Затем устройство услуг M2M объекта 155 может послать в прокси-модуль 192 средств N-SC сети AN на этапе 250 запрос на постоянную регистрацию (SL). Этот запрос может включать в себя идентификатор подписки на M2M услуги для M2M объекта, идентификатор средств D/G-SC (в зависимости от того, является ли M2M объект 155 M2M устройством или M2M шлюзом), межуровневые идентификаторы M2M устройств/шлюзов и идентификаторы любых M2M приложений (например, M2M приложение (приложения) 166 на фиг. 9), работающих под управлением устройства услуг (и поддерживаемые сервером M2M AS 62 в сети 82 M2M SP). После получения запроса на постоянную регистрацию (SL) от M2M объекта 155 прокси-модуль 192 средств M2M N-SC на основе AN может связать межуровневый идентификатор M2M D/G с IMSI M2M объекта, IP адресом и полученным ID приложения (приложений) (блок 251) и выдать запрос на постоянную регистрацию (SL) на сервер 194 средств M2M N-SC на основе SP на этапе 252. Запрос на постоянную регистрацию на этапе 252 может содержать идентификатор подписки на M2M услуги M2M объекта, идентификатор средств M2M D/G-SC, межуровневый идентификатор M2M D/G и другие необходимые параметры (или межуровневую информацию). На основе информации/состояния подписки M2M объекта на этапе 252 сервер 194 средств N-SC поставщика M2M SP может на этапе 253 получить запрос на постоянную регистрацию на уровне SL. Затем прокси-модуль 192 средств M2M N-SC сети AN посылает на M2M объект 155 на этапе 254 сообщение об успешном получении постоянной регистрации на уровне SL, реагируя тем самым на запрос на постоянную регистрацию (SL) M2M объекта, посланный на этапе 250. На этапе 254 сообщение о получении постоянной регистрации (SL) также может предоставить M2M объекту 155 информацию о достижимости для сервера M2M AS 62 на основе SP. Далее на этапе 255 M2M объект 155 (через свое устройство услуг) может установить соединение для данных SL с сетью 82 M2M SP для требуемого M2M приложения (приложений). В одном варианте, используя существующие/известные на данный момент процедуры 3GPP (которые здесь для краткости не описываются), шлюз P-GW 147 может принять информацию QoS для PDN соединения, используемого приложением (приложениями) M2M объекта, для соединения с сервером M2M AS 62 поставщика SP, как показано в блоке 256.

На фиг. 16 показан другой приведенный в качестве примера набор последовательностей операций по обработке вызова высокого уровня согласно одному варианту настоящего изобретения для постоянного подключения M2M объекта (например, M2M объекта 155 на фиг. 9) к выбранному поставщику M2M SP (например, M2M SP 82 на фиг. 11) через сеть доступа 3GPP (например, сеть AN 84 доступа 3GPP на фиг. 11). Последовательности обработки вызова на фиг. 16 относятся к случаю 3 (B), описанному в приведенном выше разделе VI (в Части 2 настоящего изобретения) и относятся к архитектуре для активации M2M услуг, подобной архитектуре 190 на фиг. 11 (то есть в сети AN могут находиться средства M2M N-SC 192 (но в сети AN не допускается использование прокси-модуля M2M N-SC), в то время как сеть SP разворачивает средства N-SC в виде сервера 194 N-SC). Этапы 240-249 на фигурах 15 и 16 аналогичны, и поэтому они здесь повторно не обсуждаются. Как упоминалось в описании случая 3 (В) в разделе VI, приведенном выше, присвоенное имя APN для N-SC (во время начального подключения для первого обслуживания услуг), использованное на этапе 241 может указать на P-GW 147, который связан с сетью 82 поставщика SP. Таким образом, когда в блоке 246 установлено PDN соединение согласно существующим/известным процедурам 3GPP, шлюз P-GW 147 может получить профиль подписки на доступ для M2M устройства/шлюза, который включает в себя межуровневый идентификатор M2M D/G и другие параметры, необходимые для межуровневого взаимодействия с сервером 194 средств M2M N-SC сети поставщика SP. Аналогичным образом, используя существующие процедуры 3GPP, шлюз P-GW 147 может получить информацию о качестве (QoS) для PDN соединения, используемого приложением (приложениями) M2M объекта, для соединения с сервером AS 62 поставщика SP, как показано в блоке 262. Поскольку разворачивание N-SC 192 в сети AN 3GPP не разрешено (даже в том случае, если они присутствуют и развернуты в сети AN, как в варианте по фиг. 16) устройство услуг M2M объекта (например, устройство 162 услуг для M2M объекта 155 на фиг. 9) может послать запрос на постоянную регистрацию (SL) непосредственно на сервер 194 M2M N-SC сети SP на этапе 263. Параметры, содержащиеся в этом запросе, могут быть идентичны параметрам, показанным на этапе 250 (фиг. 15), и поэтому они здесь повторно не описываются. Сервер 194 средств M2M SP N-SC может затем напрямую ответить M2M объекту, как показано на этапе 264. Поскольку содержание ответных сообщений на этапе 264 (фиг. 16) и на этапе 254 (фиг. 15) по существу аналогичны, дополнительное обсуждение этапа 264 на фиг. 16 здесь для краткости опущено. Таким образом, вместо получения ответа от прокси-модуля N-SC сети AN (как показано на этапе 254 по фиг. 15) M2M объект 155 получает ответ на свой запрос на постоянную регистрацию (SL) непосредственно от сервера 194 M2M SP N-SC в варианте по фиг. 16. Далее на этапе 265 M2M объект 155 (через свое устройство услуг) может установить соединение для передачи данных (SL) с сетью 82 поставщика M2M SP для требуемого M2M приложения (приложений).

Раздел VIII: Каким образом сеть AN 3GPP отличает начальное подключение к услугам от постоянного подключения к услугам

Для сети доступа AN 3GPP достаточно важно иметь возможность отличать начальное подключение для первого обслуживания M2M объекта от последующего постоянного подключения. Указанное различие между начальным подключением для первого обслуживания и постоянным подключением важно, поскольку разные процедуры, имеющие отношение к каждому аспекту (как подробно обсуждалось выше), а именно специальные процедуры начального подключения обычно выполняются только один раз в течение срока эксплуатации M2M объекта, как упоминалось выше, в то время как постоянное подключение может выполняться часто. В этом разделе кратко обсуждается, каким образом сеть доступа 3GPP (например, AN 84 на фигурах 11-12) может реализовать эту возможность различения (начального подключения и постоянного подключения).

Начальное подключение для первого обслуживания: Случай 1 (M2M объект снабжен APN с нулевым значением (NULL APN). Сеть AN 3GPP может выполнить описанные ниже этапы для принятия решения о том, что текущий запрос на подключение (от M2M объекта, такого как, например, M2M объект 155 на фиг. 9) относится к начальному подключению для первого обслуживания.

(1) Поскольку M2M объект еще не выполнил начальное подключение для первого обслуживания, профиль подписки на доступ M2M объекта на сервере HSS (например, HSS 142 на фигурах 12, 14 и т.д.) может иметь только APN используемых по умолчанию средств (M2M N-SC) сети AN.

(2) M2M объект использует при начальном подключении NULL APN (или отсутствие APN (поскольку в этом случае M2M объект не обеспечен APN используемых по умолчанию средств M2M N-SC сети AN).

(3) Объект MME (например, MME 200 на фигурах 12, 14 и т.д.) может извлечь профиль подписки на доступ M2M объекта из HSS наряду с другой информацией. Поскольку сервер HSS имеет только APN используемых по умолчанию средств M2M N-SC сети AN (смотри этап (1), приведенный выше), объект MME может заключить на основе информации, полученной от сервера HSS, что это подключение следует рассматривать как начальное подключение для первого обслуживания.

(4) Объект MME может использовать APN используемых по умолчанию средств M2M N-SC сети AN для создания сессии на подходящем шлюзе SGW (например, HSGW 145 на фиг. 12 или SGW на фиг. 14) и подходящем шлюзе Р-GW (например, P-GW 147 на фигурах 12, 14 и т.д.).

(5) После успешного завершения начального подключения услуг сервер HSS и M2M объект могут быть обновлены (например, с помощью используемых по умолчанию средств M2M N-SC сети AN) с использованием APN постоянных средств M2M N-SC, добавляемого в профиль подписки на доступ M2M объекта.

Первое начальное подключение услуг: Случай 2 (M2M объект обеспечен APN используемых по умолчанию средств M2M N-SC сети AN) в отличие от случая 1, обсужденного выше, в случае 2 M2M объект обеспечен APN используемых по умолчанию средств M2M N-SC сети AN (например, N-SC 192 на фигурах 11 и 14). Затем сеть AN 3GPP может выполнить описанные ниже этапы для принятия решения о том, что текущий запрос на подключение от M2M объекта относится к начальному подключению для первого обслуживания.

(1) Поскольку M2M объект еще не выполнил начальное подключение для первого обслуживания, профиль подписки на доступ для M2M объекта в HSS может иметь только APN используемых по умолчанию средств M2M N-SC сети AN.

(2) M2M объект использует APN используемых по умолчанию средств M2M N-SC сети AN при начальном подключении.

(3) Объект MME может выбрать профиль подписки на доступ для M2M объекта из HSS в числе другой информации. Поскольку HSS имеет только APN используемых по умолчанию средств M2M N-SC сети AN (смотри этап (1), описанный выше), объект MME может заключить на основе информации, полученной от HSS, что данное подключение следует считать начальным подключением для первого обслуживания.

(4) Объект MME может использовать имя APN используемых по умолчанию средств M2M N-SC сети AN для создания сессии на подходящем шлюзе SGW и подходящем шлюзе P-GW.

(5) После успешного завершения начального подключения услуг сервер HSS и M2M объект можно обновить (например, с помощью используемых по умолчанию средств M2M N-SC сети AN) с использованием имени APN постоянных средств M2M N-SC, добавляемого к профилю подписки на доступ для M2M объекта.

Постоянное подключение услуг: случай 1 (M2M объект обновляется с использованием APN постоянных средств M2M N-SC сети APN). Этот случай 1 относится к ситуации, когда и M2M объект и HSS обновляют с использованием имени APN постоянных средств M2M N-SC сети AN в течение начального подключения для первого обслуживания. Затем сеть AN 3GPP выполняет следующие этапы для принятия решения о том, что текущий запрос на подключение от M2M объекта относится к постоянному подключению к выбранному им поставщику M2M SP.

(1) Поскольку M2M объект уже выполнил начальное подключение для первого обслуживания, профиль подписки на доступ для M2M объекта в HSS может иметь и APN используемых по умолчанию средств M2M N-SC сети AN, и APN постоянных/выделенных средств M2M N-SC сети AN (например APN средств N-SC на основе AN, которые развернуты в виде постоянных средств M2M N-SC для обслуживания M2M SP, выбранного M2M объектом).

(2) M2M объект может использовать выделенное/постоянное имя APN при повторном подключении (или постоянном подключении), либо подключении после перезагрузки.

(3) Объект MME может выбрать профиль подписки на доступ для M2M объекта из HSS в числе другой информации. Поскольку HSS имеет имена APN используемых по умолчанию и постоянных средств M2M N-SC сети AN (смотри этап (1), описанный выше), объект MME может заключить на основе информации, полученной от HSS, что данное подключение следует считать постоянным подключением услуг.

(4) Затем объект MME может использовать имя APN постоянных средств M2M N-SC сети AN для создания сессии с подходящим шлюзом SGW и подходящим шлюзом P-GW.

Постоянное подключение услуг: Случай 2 (M2M объект не обновляется с использованием APN постоянных средств M2M N-SC сети APN). В отличие от рассмотренного выше случая 1, случай 2 относится к ситуации, когда M2M объект (но не сервер HSS) не обновляется с использованием APN постоянных средств M2M N-SC сети AN во время начального подключения для первого обслуживания. Затем сеть AN 3GPP может выполнить описанные ниже этапы для принятия решения о том, что текущий запрос на подключение, поступивший от M2M объекта предназначен для постоянного подключения к выбранному поставщику M2M услуг.

(1) Поскольку M2M объект уже выполнил начальное подключение для первого обслуживания, профиль подписки на доступ для M2M объекта в HSS может иметь имена APN, как используемых по умолчанию, так и постоянных средств M2M N-SC сети AN.

(2) Поскольку M2M объект не обновлялся с использованием APN постоянных средств M2M N-SC сети AN после начального подключения для первого обслуживания, объект M2M может использовать NULL APN (нулевое имя, или не использовать APN) при постоянном подключении.

(3) Объект MME может выбрать профиль подписки на доступ для M2M объекта из HSS в числе другой информации. Поскольку HSS имеет имена APN как используемых по умолчанию, так и постоянных средств M2M N-SC сети AN (смотри этап (1), обсужденный выше), объект MME может заключить (на основе информации, полученной от сервера HSS), что данное подключение следует считать постоянным подключением.

Заметим, что в конкретных вариантах объект MME может извлекать профиль подписки на доступ для M2M объекта из HSS (как обсуждалось выше для каждого случая, описанного в разделе VIII), если запись MME показывает, что профиль объекта M2M имеет сконфигурированные используемые по умолчанию средства M2M N-SC.

Раздел IX: Приведенные в качестве примера варианты активации M2M услуг для M2M объекта, который использует 3GPP доступ или доступ, не являющийся доступом 3GPP

Далее обобщаются некоторые существенные аспекты основополагающих принципов настоящего изобретения, которые обеспечивают техническое решение по активации M2M услуг для M2M объектов, которые используют доступ 3GPP и 3GPP EPC. Основополагающие принципы настоящего изобретения также применимы к доступам, не являющимся доступом 3GPP (например, eHRPD), в которых используется 3GPP EPC. Конкретные варианты настоящего изобретения также определяют динамический механизм для согласования транспортного уровня сети доступа и уровня M2M услуг в соответствии с обработкой M2M услуг, предлагающихся M2M устройству/шлюзу, с использованием сети доступа 3GPP и ядра 3GPP EPC. Настоящее изобретение разрешает разворачивание архитектуры уровня M2M SL (используемую оператором сети 3GPP AN), которая соответствует архитектуре ETSI M2M SL, предоставляя достаточную свободу (для оператора сети AN 3GPP) выбора поставщика M2M услуг и обеспечивая при этом возможность полного контроля со стороны оператора сети AN 3GPP за своей собственной сетью, и предоставляя возможность совместного использования с поставщиком M2M SP межуровневой информации M2M устройства/шлюза в динамическом режиме.

Вариант 1: Этот вариант относится к техническому решению согласно основополагающим принципам настоящего изобретения, которое применимо к M2M устройству/шлюзу, поддерживающему доступ 3GPP (например, E-UTRAN) и использующему ядро 3GPP EPC и/или M2M устройство/шлюз, которое поддерживает доступ, не являющийся доступом 3GPP (например, cdma2000 eHRPD), но использует ядро 3GPP EPC.

Вариант 2: Этот вариант относится к техническому решению согласно основополагающим принципам настоящего изобретения, которое активирует начальное подключение M2M услуг для M2M устройств/шлюзов (которые используют 3GPP доступ (например, E-UTRAN) или доступ, не являющийся доступом 3GPP (например cdma2000 eHRPD), подсоединяемый и обслуживаемый ядром 3GPP EPC), где M2M устройство/шлюз могут быть динамически сконфигурированы выбранным поставщиком M2M услуг с межуровневым идентификатором M2M устройства/шлюза, когда оператор сети доступа 3GPP полностью осведомлен об указанной динамической конфигурации и имеет доступ к необходимой межуровневой информации.

Вариант 3: Этот вариант относится к техническому решению согласно основополагающим принципам настоящего изобретения, которое обеспечивает активацию M2M услуг (после начального подключения) для M2M устройств/шлюзов (независимо от того, используют ли они доступ 3GPP или доступ, не являющийся доступом 3GPP, подсоединяемый и обслуживаемый ядром 3GPP EPC), где (через ядро 3GPP EPC) обеспечено транспортное соединение с сервером M2M приложений выбранного поставщика M2M услуг для M2M D/G.

Вариант 4: Этот вариант относится к техническому решению согласно основополагающим принципам настоящего изобретения, которое активирует точку привязки 3GPP EPC (например, шлюз P-GW и/или шлюз SGW), где известен тип трафика и M2M приложения, которые используют транспортное соединение, предоставленное M2M объекту (который может использовать доступ 3GPP или доступ, не являющийся доступом 3GPP, для подсоединения и обслуживания ядром 3GPP EPC) для соединения M2M объекта с сервером M2M приложений выбранного поставщика M2M SP.

Вариант 5: Этот вариант относится к техническому решению согласно основополагающим принципам настоящего изобретения, которое обеспечивает динамическое обновление базы данных домашней подписки сети доступа 3GPP (например, HSS) с использованием обновленного профиля подписки абонента M2M доступа (то есть M2M объекта, имеющего подписку в сети AN 3GPP на M2M услуги). Указанный обновленный профиль подписки может включать в себя динамически распределенный межуровневый идентификатор M2M D/G и обновленные имена APN средств N-SC (например, SL сигнализация и имена APN данных SL), которые используют для идентификации соединения (соединений) M2M устройства/шлюза с сервером приложений и средствами M2M N-SC поставщика M2M SP.

Вариант 6: Этот вариант относится к техническому решению согласно основополагающим принципам настоящего изобретения, которое обеспечивает динамическое обновление сервера политики сети доступа 3GPP (например, PCRF) с использованием обновленного профиля политики абонента M2M доступа, который включает в себя динамически распределенный межуровневый идентификатор M2M D/G, разрешенное M2M приложение (приложения) и связанные с ними правила QoS.

Вариант 7: Этот вариант относится к техническому решению согласно основополагающим принципам настоящего изобретения, которое предоставляет поставщику M2M услуг возможность предлагать свою начальную активацию M2M услуг (во время начального подключения для первого обслуживания) M2M объекту (который может использовать доступ 3GPP и доступ, не являющийся доступом 3GPP, для подсоединения и обслуживания ядром 3GPP EPC) и для динамического конфигурирования данного M2M объекта с межуровневым идентификатором M2M объекта/шлюза выбранного поставщика M2M SP, сконфигурированного для M2M объекта.

Вариант 8: Этот вариант относится к техническому решению согласно основополагающим принципам настоящего изобретения, которое предоставляет поставщику M2M услуг возможность предлагать начальную активацию M2M услуг (во время начального подключения для первого обслуживания) M2M объекту (который может использовать доступ 3GPP ли доступ, не являющийся доступом 3GPP) для полсоединения и обслуживания ядром 3GPP EPC) и для динамического обновления сети доступа 3GPP с использованием межуровневого идентификатора M2M устройства/шлюза поставщика M2M SP, сконфигурированного для M2M объекта.

Вариант 9: В этом варианте поставщик M2M услуг может координировать свои действия с сетью доступа 3GPP и иметь имя APN постоянных средств M2M N-SC сети AN и межуровневый идентификатор M2M устройства/шлюза, заранее обеспеченные на M2M объекте, у поставщика M2M услуг и в сети доступа 3GPP. В этом случае M2M объекту может не потребоваться начальное подключение, поскольку цель этой процедуры достигается посредством предварительного обеспечения упомянутыми параметрами. В этом варианте архитектура для активации M2M услуг, которую использует поставщик M2M SP, отражена в соглашении (SLA) между оператором доступа 3GPP и поставщиком M2M SP, и также может быть отражена затем в имени (APN) постоянных средств M2M N-SC сети AN, которое заранее предоставлено устройству доступа M2M объекта в качестве части подписки на 3GPP доступ для M2M объекта.

Хотя признаки и элементы изобретения были описаны выше в конкретных комбинациях, каждый из этих признаков или элементов можно использовать по отдельности без других признаков и элементов или в различных комбинациях с другими признаками и элементами или без других признаков и элементов. Заметим, что разворачивание прокси-модуля средств M2M N-SC и активация M2M услуг в сотовой сети AN (включающей в себя сеть доступа 3GPP) и относящиеся к этому последовательности операций вызова/потоки сообщений могут быть реализованы аппаратными средствами и/или программными средствами (которые могут представлять собой компьютерную программу, исполняемый код, программно-аппаратные средства и т.д., внедренные в считываемый компьютером носитель хранения данных, такой как RAM, ROM, полупроводниковая память или другие носители/запоминающие устройства для хранения данных, упомянутые выше).

Выше была описана архитектура для активации M2M услуг для сотовой сети AN, позволяющая оператору сотовой сети AN не только разворачивать свои средства M2M SC в виде сервера средств M2M SC в своей сетевой области, но также использовать свои M2M SC для функционирования в виде прокси-модуля средств M2M SC при осуществлении связи с сетью поставщика M2M услуг, которая также использует сервер средств M2M SC. Функционирование прокси-модуля средств M2M SC в сотовой сети AN базируется на передачах в плоскости сигнализации между средствами SC M2M устройства/шлюза и сервером средств M2M SC поставщика SP. Кроме того, прокси-модуль средств M2M SC предоставляет сотовой сети AN доступ к межуровневой (транспортный уровень и уровень услуг) информации, необходимой для активации M2M услуг в сотовой сети AN. Такое техническое решение на основе прокси-модуля позволяет сотовой сети AN обслуживать все типы поставщиков M2M услуг и избавляет поставщика M2M AP от необходимости поддерживать разные интерфейсы для взаимодействия с сотовой сетью AN.

Как обсуждалось выше, архитектура для активации M2M услуг согласно некоторым вариантам настоящего изобретения обеспечивает гибкость и предоставляет оператору сотовой сети AN возможность предлагать свои услуги доступа (в том числе транспортные уровни) для реализации M2M услуг согласно архитектуре ETSI M2M SL, причем таким путем, который позволяет оператору сотовой сети AN достичь следующего: (а) использовать единую модель разворачивания посредством разворачивания средств M2M SC в сети с возможностью обслуживания всех типов M2M услуг; (b) иметь легкий доступ ко всей информации, которая необходима для межуровневых функциональных возможностей. Эта информация может быть использована для того, чтобы помочь оператору сотовой сети AN предлагать свою сеть AN в виде более интеллектуального «битпайпа»; (с) обслуживать других поставщиков M2M услуг, которые используют архитектуру, не являющуюся архитектурой ETSI M2M SL; (d) добиться гибкости при маршрутизации M2M трафика в гостевой сети на основе политики оператора (домашней сотовой сети AN) и подписки на услуги M2M. Общая архитектура активации M2M услуг согласно конкретным вариантам настоящего изобретения позволяет также поставщику M2M SP разворачивать свои услуги, одновременно используя множество технологий доступа при одной и той же модели разворачивания.

Выше также было описано техническое решение по активации M2M услуг для активации M2M услуг для M2M объекта, который поддерживает доступ, являющийся или не являющийся доступом 3GPP, для подсоединения и обслуживания ядром 3GPP EPC. Это техническое решение позволяет сети AN предлагать транспортное соединение для M2M объекта через ядро 3GPP EPC к выбранному M2M объектом поставщику M2M SP. Первое подключение M2M объекта к сети AN принудительно адресуется к APN используемых по умолчанию средств M2M N-SC сети AN независимо от любого другого APN, полученного от M2M объекта. Используемые по умолчанию средства M2M N-SC сети AN обеспечивают начальную регистрацию (M2M SL) M2M объекта у выбранного поставщика M2M SP. Будущее постоянное подключение M2M объекта к сети SP может быть адресовано к APN постоянных средств M2M N-SC на основе AN, которые обслуживают M2M SP.

Таким образом, в приведенном в качестве примера случае использования сети доступа 3GPP некоторые варианты настоящего изобретения:

(а) позволяют оператору 3GPP AN иметь полную информацию о межуровневом идентификаторе M2M объекта, типе трафика, который используется через транспортное соединение сети AN, и о M2M приложениях, которые используют предоставленное транспортное соединение;

(b) позволяет поставщику M2M SP предлагать свой вариант начальной активации услуг M2M объекту, который использует любой сотовый доступ, и динамически конфигурировать выбранный межуровневый идентификатор M2M D/G поставщика M2M SP и одновременно находить M2M объект, как только он зарегистрирован;

(с) предлагает динамическое техническое решение для обновления подписки на доступ для M2M объекта с использованием динамически распределенного межуровневого идентификатора M2M D/G и обновленного имени APN средств M2M N-SC (то есть SL сигнализация и имена SL данных); и

(d) обеспечивает динамическое техническое решение для обновления профиля политики абонента M2M доступа с использованием функции PCRF, применяющей динамически распределенный межуровневый идентификатор M2M устройства/шлюза, а также M2M приложения и соответствующих параметров QoS.

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

Изобретение относится к области межмашинной связи. Техническим результатом является повышение структурированности и гибкости обеспечения межмашинной связи. Способ содержит этапы: прием начального запроса от M2M объекта на подключение к сети M2M SP, получение имени точки доступа приложения используемых по умолчанию сетевых служебных средств М2М с использованием идентификатора подписки на М2М доступ, соединение М2М объекта с приложением используемых по умолчанию М2М сетевых служебных средств, обеспечение начальной регистрации М2М объекта на уровне услуг М2М. 4 н. и 21 з.п. ф-лы, 17 ил.

1. Способ использования беспроводной сети (84) доступа (AN) на основе развитого пакетного ядра (ЕРС) (78) Проекта партнерства 3-го поколения (3GPP) для активации подключения межмашинного (М2М) объекта (155) к сети (82, 88) поставщика М2М услуг (SP), выбранной М2М объектом, причем способ содержит выполнение следующих этапов с использованием сети AN:

прием (176) начального запроса от М2М объекта на подключение к сети М2М SP, причем начальный запрос содержит идентификатор подписки на М2М доступ, характерный для объекта;

получение (177) имени точки доступа (APN) приложения (192) используемых по умолчанию сетевых служебных средств (N-SC) М2М с использованием идентификатора подписки на М2М доступ независимо от любого другого APN, принятого от М2М объекта в качестве части начального запроса;

соединение (178) М2М объекта с приложением используемых по умолчанию М2М N-SC с использованием APN используемых по умолчанию М2М N-SC AN; и

обеспечение (179) начальной регистрации М2М объекта на уровне услуг (SL) М2М в сети М2М SP с использованием приложения используемых по умолчанию М2М N-SC AN.

2. Способ по п. 1, в котором М2М объектом является одно из следующего:

М2М устройство; и

М2М шлюз.

3. Способ по п. 1, в котором идентификатором подписки на М2М доступ является по меньшей мере одно из следующего:

международный идентификатор мобильного абонента (IMSI), присвоенный М2М объекту; и

идентификатор доступа к сети (NAI), присвоенный М2М объекту.

4. Способ по п. 1, в котором этап получения APN приложения используемых по умолчанию М2М N-SC AN включает в себя:

использование идентификатора подписки на М2М доступ для доступа к соответствующему профилю подписки на М2М доступ, характерному для объекта, в AN, причем профиль подписки на М2М доступ на основе AN содержит APN приложения используемых по умолчанию М2М N-SC AN; и

извлечение APN приложения используемых по умолчанию М2М N-SC AN из профиля подписки на М2М доступ на основе AN, независимо от любого APN, принятого от М2М объекта в качестве части начального запроса.

5. Способ по п. 4, дополнительно содержащий выполнение по меньшей мере одного из следующих этапов с использованием приложения используемых по умолчанию М2М N-SC AN:

обновление (236) профиля подписки на М2М доступ на основе AN с использованием по меньшей мере одной информации из нижеперечисленного:

межуровневого (A-Layers) М2М идентификатора М2М объекта, принятого от сети М2М SP, и/или

APN приложения постоянных М2М N-SC на основе AN, которое обслуживает сеть М2М SP, выбранную М2М объектом;

обновление подписки на М2М доступ на основе объекта в М2М объекте с использованием по меньшей мере одной информации из нижеперечисленного:

A-Layers M2M идентификатора M2M объекта, принятого от М2М SP, и/или

APN приложения постоянных М2М N-SC на основе AN, которое обслуживает сеть М2М SP, выбранную М2М объектом; и

обновление подписки на политику М2М доступа на основе AN для М2М объекта с использованием информации о качестве обслуживания (QoS), характерной для приложения, по меньшей мере для одного М2М приложения, поддерживаемого на М2М объекте.

6. Способ по п. 5, в котором подписка на М2М доступ на основе объекта содержит по меньшей мере одну информацию из нижеперечисленного:

используется ли М2М объект только для М2М услуг;

используется ли М2М объект для М2М услуг и доступа в Интернет; и

используется ли М2М объект только для доступа в Интернет.

7. Способ по п. 1, в котором этап обеспечения начальной регистрации М2М SL включает в себя:

прием, приложением используемых по умолчанию М2М N-SC AN, идентификатора подписки на М2М услуги от М2М объекта;

исходя из принятого идентификатора подписки на М2М услуги, идентификацию, приложением используемых по умолчанию М2М N-SC AN, сети М2М SP, выбранной М2М объектом, и архитектуры М2М услуг, поддерживаемой сетью М2М SP, в отношении приложения используемых по умолчанию М2М N-SC AN; и

выполнение, приложением используемых по умолчанию М2М N-SC AN, начальной регистрации М2М SL в М2М SP на основе соответствующей архитектуры М2М услуг.

8. Способ по п. 7, в котором этап выполнения начальной регистрации М2М SL включает в себя:

прием, приложением используемых по умолчанию М2М N-SC AN, от М2М SP по меньшей мере одного из следующего:

межуровневого (A-Layers) М2М идентификатора М2М объекта;

идентификатора SC для служебных средств М2М объекта; и

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

9. Способ по п. 1, в котором этап обеспечения начальной регистрации М2М SL включает в себя:

обеспечение начальной регистрации (М2М SL) М2М объекта в М2М SP N-SC с использованием приложения используемых по умолчанию М2М N-SC AN.

10. Способ по п. 9, в котором М2М SP N-SC представляют собой сервер, а используемые по умолчанию М2М N-SC AN представляют собой прокси-модуль, который сконфигурирован для функционирования от имени сервера М2М SP N-SC, и причем этап обеспечения начальной регистрации М2М SL включает в себя:

обмен сигнальными сообщениями SL между прокси-модулем средств М2М N-SC на основе AN и сервером М2М SP N-SC с использованием интерфейса прикладного программирования (API) М2М SL для способствования начальной регистрации М2М SL объекта М2М на сервере М2М SP N-SC.

11. Способ по п. 9, дополнительно содержащий:

предоставление, М2М объекту приложением используемых по умолчанию М2М N-SC AN, по меньшей мере одного из идентификатора и информации о достижимости М2М SP N-SC;

подачу, на М2М объект приложением используемых по умолчанию М2М N-SC AN, команды на обновление приложения используемых по умолчанию М2М N-SC AN с использованием межуровневой (A-Layers) информации после успешной начальной регистрации М2М SL в М2М SP N-SC;

прием, приложением используемых по умолчанию М2М N-SC AN, А-Layers информации от М2М объекта; и

на основе принятой A-Layers информации выполнение, приложением используемых по умолчанию М2М N-SC AN, обновления с помощью APN шлюза сети пакетной передачи данных (P-GW) в AN, которое способствует последующей постоянной регистрации М2М объекта в М2М SP N-SC, по меньшей мере одного из следующего:

подписки на М2М доступ на основе AN для М2М объекта, и

подписки на М2М доступ на основе объекта, хранящейся на М2М объекте.

12. Способ по п. 9, дополнительно содержащий:

предоставление, приложением используемых по умолчанию М2М N-SC AN, М2М объекту по меньшей мере одного из идентификатора и информации о достижимости М2М SP N-SC;

запрос, приложением используемых по умолчанию М2М N-SC AN, у М2М SP N-SC на обновление используемых по умолчанию М2М N-SC AN с использованием межуровневой (A-Layers) информации после завершения этапов начальной регистрации М2М SL для М2М объекта, но перед тем как М2М SP N-SC проинформируют М2М объект об успехе начальной регистрации;

прием, приложением используемых по умолчанию М2М N-SC AN, А-Layers информации от М2М SP N-SC;

на основе принятой A-Layers информации выполнение, приложением используемых по умолчанию М2М N-SC AN, обновления с помощью APN шлюза сети пакетной передачи данных (P-GW) в AN, которое способствует последующей постоянной регистрации М2М объекта в М2М SP N-SC, по меньшей мере одного из следующего:

подписки на М2М доступ на основе AN для М2М объекта, и

подписки на М2М доступ на основе объекта, хранящейся на М2М объекте; и

индикацию, приложением используемых по умолчанию М2М N-SC AN, об успехе обновления для М2М SP N-SC, с тем чтобы дать возможность М2М SP N-SC проинформировать М2М объект об успехе начальной регистрации М2М SL.

13. Способ по п. 1, в котором этап приема начального запроса включает в себя прием от М2М объекта в качестве части начального запроса по меньшей мере одного из следующего:

NULL APN; и

APN приложения используемых по умолчанию М2М N-SC на основе AN.

14. Способ по п. 1, дополнительно содержащий выполнение следующих этапов с использованием AN:

после начальной регистрации М2М SL, обновление с использованием APN постоянных М2М N-SC, которое идентифицирует сетевой элемент на основе AN, обслуживающий сеть М2М SP, выбранную М2М объектом, по меньшей мере одного из следующего:

подписки на М2М доступ на основе AN для М2М объекта, и

подписки на М2М доступ на основе объекта, хранящейся на М2М объекте;

прием запроса на постоянное подключение от М2М объекта для повторного подключения к сети М2М SP;

установление соединения сети пакетной передачи данных (PDN) 3GPP между М2М объектом и сетевым элементом на основе AN с использованием APN постоянных М2М N-SC; и

обеспечение постоянной регистрации М2М объекта М2М SL в сети М2М SP через упомянутый сетевой элемент на основе AN.

15. Способ по п. 14, в котором сетевой элемент на основе AN включает в себя одно из следующего:

сервер постоянных М2М N-SC;

прокси-модуль постоянных М2М N-SC; и

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

16. Способ по п. 14, в котором запрос от М2М объекта на постоянное подключение включает в себя одно из следующего:

NULL APN; и

APN постоянных М2М N-SC.

17. Способ по п. 14, в котором этап установления 3GPP PDN соединения включает в себя:

извлечение APN постоянных М2М N-SC из домашнего абонентского сервера (HSS) в AN.

18. Способ по п. 14, в котором этап обеспечения постоянной регистрации М2М SL включает в себя:

прием от М2М объекта межуровневого (A-Layers) М2М идентификатора М2М объекта; и

использование A-Layers М2М идентификатора М2М объекта для идентификации М2М объекта и для определения достижимости М2М объекта во время постоянного подключения М2М объекта к сети М2М SP.

19. Беспроводная сеть (84) доступа (AN) на основе развитого пакетного ядра (ЕРС) (78) Проекта партнерства 3-го поколения (3GPP) для активации подключения межмашинного (М2М) объекта (155) к сети (82, 88) поставщика услуг (SP) М2М, выбранной М2М объектом, причем AN сконфигурирована для выполнения следующего:

приема (176) начального запроса от М2М объекта на подключение к сети М2М SP, причем начальный запрос содержит идентификатор подписки на М2М доступ, характерный для объекта;

получения (177) имени точки доступа (APN) приложения (192) используемых по умолчанию сетевых служебных средств (N-SC) М2М на основе AN с использованием идентификатора подписки на М2М доступ независимо от любого другого APN, принятого от М2М объекта в качестве части начального запроса;

соединения (178) М2М объекта с приложением используемых по умолчанию М2М N-SC с использованием APN приложения используемых по умолчанию М2М N-SC AN; и

обеспечения (179) начальной регистрации, на уровне услуг (SL) М2М, М2М объекта в сети М2М SP с использованием приложения используемых по умолчанию М2М N-SC AN.

20. AN по п. 19, дополнительно сконфигурированная для выполнения следующего:

после начальной регистрации М2М SL, обновления с использованием APN постоянных М2М N-SC, которое идентифицирует сетевой элемент на основе AN, обслуживающий сеть М2М SP, выбранную М2М объектом, по меньшей мере одного из следующего:

подписки на М2М доступ на основе AN для М2М объекта, и

подписки на М2М доступ на основе объекта, хранящейся на М2М объекте;

приема запроса на постоянное подключение от М2М объекта для повторного подключения к сети М2М SP;

установления (180) соединения 3GPP между М2М объектом и упомянутым сетевым элементом на основе AN с использованием APN постоянных М2М N-SC; и

обеспечение постоянной регистрации М2М SL для М2М объекта в сети М2М SP через упомянутый сетевой элемент на основе AN.

21. Межмашинный (М2М) объект (155), сконфигурированный для связи с сетью (82, 88) поставщика услуг (SP) М2М через развитое пакетное ядро (ЕРС) (78) Проекта партнерства 3-го поколения (3GPP) на основе беспроводной сети (84) доступа (AN), причем М2М объект содержит:

память (158), сконфигурированную для запоминания идентификатора подписки на М2М доступ для М2М объекта; и

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

посылки начального запроса в AN для подключения к сети М2М SP, причем начальный запрос содержит идентификатор подписки на М2М доступ,

соединения с приложением используемых по умолчанию сетевых служебных средств (N-SC) М2М на основе AN с использованием их имени точки доступа (APN) независимо от любого другого APN, посланного процессором в AN, в качестве части начального запроса, и

выполнения начальной регистрации на уровне услуг (SL) М2М для М2М объекта в сети М2М SP с использованием приложения используемых по умолчанию М2М N-SC AN.

22. М2М объект по п. 21, в котором память дополнительно сконфигурирована для запоминания по меньшей мере одного из следующего:

служебных средств (SC) М2М, характерных для объекта;

одного или более М2М приложений;

идентификатора подписки на М2М услуги, идентифицирующего сеть М2М SP и архитектуру М2М услуг, поддерживаемую сетью М2М SP;

подписки на М2М доступ, связанной с идентификатором подписки на М2М доступ;

APN приложения используемых по умолчанию М2М N-SC на основе AN;

нулевого APN;

APN постоянных М2М N-SC, которое идентифицирует сетевой элемент на основе AN, обслуживающий сеть М2М SP;

межуровневого (A-Layers) М2М идентификатора М2М объекта для идентификации М2М объекта и для определения достижимости М2М объекта;

идентификатора и информации о достижимости М2М SP N-SC; и

учетные данные безопасности М2М объекта.

23. М2М объект по п. 21, в котором процессор дополнительно сконфигурирован для выполнения следующего в качестве части соединения с приложением используемых по умолчанию М2М N-SC AN:

установления соединения сети пакетной передачи данных (PDN) 3GPP между М2М объектом и приложением используемых по умолчанию М2М N-SC AN с использованием APN приложения используемых по умолчанию М2М N-SC AN.

24. М2М объект по п. 21, в котором процессор дополнительно сконфигурирован для выполнения следующего:

после начальной регистрации М2М SL, посылки в AN запроса на постоянное подключение для повторного подключения к сети М2М SP;

установления соединения сети пакетной передачи данных (PDN) 3GPP между М2М объектом и сетевым элементом на основе AN, обслуживающим сеть М2М SP; и

выполнения постоянной регистрации М2М SL для М2М объекта в сети М2М SP через сетевой элемент на основе AN.

25. Способ использования сотовой сети доступа (AN) для подключения межмашинного (М2М) объекта к сети поставщика услуг (SP) М2М, выбранной М2М объектом, содержащий:

прием (176), посредством AN, начального запроса от М2М объекта на подключение к сети М2М SP;

соединение (178), посредством AN, М2М объекта с приложением используемых по умолчанию сетевых служебных средств (N-SC) М2М с использованием имени точки доступа (APN) приложения используемых по умолчанию М2М N-SC AN независимо от любого другого APN, принятого от М2М объекта в качестве части начального запроса; и

обеспечение (179), посредством AN, регистрации на уровне услуг (SL) М2М для М2М объекта в сети М2М SP с использованием приложения используемых по умолчанию М2М N-SC AN.