АРХИТЕКТУРА ПОДДЕРЖКИ М2М-УСЛУГ ДЛЯ СОТОВЫХ СЕТЕЙ ДОСТУПА

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

Данная заявка испрашивает приоритет предварительной заявки на патент (США) № 61/508,243, поданной 15 июля 2011 года, и предварительной заявки на патент (США) № 61/510,301, поданной 21 июля 2011 года, раскрытия сущности обеих из которых полностью содержатся в данном документе по ссылке. Данная заявка связана с находящейся одновременно на рассмотрении принадлежащей одному и тому же правообладателю заявкой на патент (США), озаглавленной "Dynamic M2M services enablement Solution Over 3GPP Access Networks", с порядковым номером 13/517,733.

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

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

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

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

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

В общем, M2M-связь также может называться "M2M-услугами", которые привязываются к "уровню услуг", в то время как сотовая сеть доступа (AN) (которая подробнее поясняется ниже) может предоставлять "транспортный уровень" для осуществления M2M-связи. Для обеспечения высокой гибкости работы любой архитектуры поддержки M2M-услуги с возможностью предлагать M2M-услуги свободно и независимо от оператора сети доступа, для любой такой архитектуры поддержки M2M-услуг может быть предпочтительным основываться на разделении между транспортными уровнями (на основе сети доступа) и уровнями услуг (на основе SP-сети). С учетом этих особенностей, технический комитет по стандарту M2M Европейского института стандартизации в области телекоммуникаций (ETSI M2M TC) работает над определением архитектуры уровня M2M-услуг (SL), которая содержит следующие основные принципы:

(I) Общие аспекты. (a) Архитектура поддержки M2M-услуг, которая является независимой от доступа (т.е. по сути независимой от базовой технологии на основе сотовой сети доступа). (b) Слабосвязанная архитектура между транспортными уровнями и уровнями услуг. (c) Отсутствие необходимости внесения изменений в M2M-услуги при перемещении из одной сети доступа в другую. (d) Одновременный доступ к идентичному уровню M2M-услуг из различных сетей доступа.

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

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

Фиг. 1 иллюстрирует архитектуру 10 поддержки M2M-услуг с использованием сотовой сети 12 доступа. Архитектура 10 на фиг. 1 показывает сотовую сеть 12 доступа, подключенную к сети 14 поставщика M2M-услуг (SP) с учетом вышеуказанных трех принципов, заданных посредством ETSI M2M TC. Для удобства и простоты пояснения, термины "сеть доступа" или "транспортная сеть" могут быть использованы в данном документе как включающие в себя не только часть сети радиодоступа (RAN) (содержащую, например, базовую станцию с/без контроллера базовой станции) сети оператора услуг сотовой связи, но также и другие части (например, сотовое транзитное соединение и базовую сеть). Аналогично, термины "поставщик M2M-услуг" или "M2M SP" и "M2M SP-сеть" могут быть использованы взаимозаменяемо в данном документе как означающие M2M SP-сеть 14 (и аналогичные другие сети, показанные на других чертежах в данном документе и поясненные ниже). Может быть возможно то, что поставщик M2M-услуг также является оператором или поставщиком сотовой сети 12 доступа. С другой стороны, M2M SP может быть независимым от поставщика услуг на основе сотовой сети доступа, но может иметь деловые отношения с оператором сотовой сети в целях функциональной совместимости.

Как показано на фиг. 1, сотовая сеть 12 доступа может включать в себя несколько узлов 16-18 сотовой связи, каждый из которых находится в пределах покрытия радиосвязью соответствующей базовой станции 20-22 (BS) или базовой приемо-передающей станции (BTS). Эти базовые станции 20-22 могут принимать беспроводную связь (как указано посредством линий 23A-23C радиосвязи) из различных объектов 24-32 M2M-связи (пояснены подробно ниже со ссылкой на фиг. 2), работающих в домене 34 M2M-устройств, и перенаправлять принимаемую связь в часть 36 M2M-ядра сотовой сети 12. M2M-ядро 36 может включать в себя часть 38 сотового транзитного соединения и сотовую базовую сеть 40 (CN). В случае базовой станции 20-22 третьего поколения (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) IEEE 802.16e и т.д. Базовая сеть 40 (CN), с другой стороны, может предоставлять логические, служебные и управляющие функции (например, управление абонентскими учетными записями, биллинг, управление мобильностью абонентов и т.д.), возможности подключения по Интернет-протоколу (IP) и межсетевое взаимодействие с другими сетями (например, Интернетом) или объектами, поддержку роуминга и т.д. CN 40 может представлять собой, например, CN на основе Партнерского проекта третьего поколения (3GPP), CN на основе Партнерского проекта третьего поколения 2 (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-приложений (AS) в M2M SP 14 с использованием надлежащего интерфейса прикладного программирования (API) (который может включать в себя полнофункциональный интерфейс, одну функцию или набор специализированных API), чтобы за счет этого упрощать предоставление различных M2M-услуг, ассоциированных с M2M-приложениями, поддерживаемыми посредством M2M SP 14.

Фиг. 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-шлюзом 26, который может выступать в качестве концентратора данных, принимаемых из таких различных 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-устройство". Кроме того, здесь следует отметить, что объект или устройство 50 M2M-связи может представлять пользовательское оборудование (UE) или мобильную станцию (MS) (также известную под различными аналогичными терминами, такими как "мобильный телефон", "беспроводной телефон", "беспроводное устройство", "терминал" и т.д.), надлежащим образом выполненную для M2M-связи. Некоторые примеры таких мобильных переносных телефонов/устройств включают в себя сотовые телефоны или устройства для передачи данных (например, персональное цифровое устройство (PDA) или устройство поискового вызова), смартфоны (например, iPhone™, Android™, Blackberry™ и т.д.), компьютеры, устройства 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-устройствах и шлюзах. Сокращенная версия "D/G-SC" может быть использована в нижеприведенном пояснении, чтобы означать оба из этих SC совместно. M2M-устройство 50 может считаться поддерживающим доступ к сотовой сети 12 (например, 3GPP-доступ) логически, как если оно представляет собой комбинацию двух логических M2M-устройств - транспортного M2M-устройства/M2M-устройства 56 доступа и устройства 58 M2M-услуг. (Хотя не указывается в данном документе или не всегда упоминается ниже для краткости, следует понимать, что когда M2M-объект 50 представляет собой M2M-шлюз, ссылки с номерами "56" и "58" могут означать транспортный M2M-шлюз/M2M-шлюз доступа и шлюз M2M-услуг, соответственно). Транспортное M2M-устройство/M2M-устройство 56 доступа может поддерживать все аспекты 3GPP-радиоинтерфейса доступа и 3GPP-сети доступа. С другой стороны, устройство 58 M2M-услуг может поддерживать все аспекты, которые связаны с уровнем M2M-услуг (SL). Такая логическая конфигурация может отражать вышеупомянутое разделение между транспортными уровнями и уровнями услуг. Таким образом, например, M2M-устройство 56 доступа может иметь идентификатор устройства (для доступа на транспортном уровне к сотовой сети 12), который отличается от идентификатора устройства (который используется на уровне услуг) для устройства 58 M2M-услуг. Кроме того, устройство 58 M2M-услуг может включать в себя идентификатор M2M-приложения (не показан) и идентификатор подписки на M2M-услуги (не показан), чтобы выполнять операции на уровне услуг, тогда как транспортное M2M-устройство 56 может включать в себя идентификатор подписки в M2M-сети доступа (не показан) и адрес M2M-сети доступа (не показан), чтобы поддерживать интерфейс доступа с сотовой сетью 12 доступа с использованием транспортного уровня. Таким образом, в случае M2M-приложения, одна часть приложения может постоянно размещаться в M2M AS 46, тогда как соответствующая часть может постоянно размещаться в M2M-объекте 50 (в качестве части M2M-приложения(й) 52). В этом отношении устройство 58 M2M-услуг может принимать конкретную для M2M-объекта часть приложения и использовать M2M-устройство 56 доступа для того, чтобы осуществлять доступ к M2M AS 46 в SP-сети 14 с использованием сотовой сети 12 для транспортировки.

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

Из вышеприведенного пояснения следует отметить, что ETSI M2M TC указывает независимую от доступа архитектуру уровня M2M-услуг (SL) (т.е. архитектуру, показанную на фиг. 1 и подробнее поясненную в технической спецификации (TS) ETSI 102.69, озаглавленной "Machine-to-Machine communications (M2M); Functional architecture"), так что M2M SP может предлагать M2M-услуги, независимые от конкретного типа сети доступа, используемой посредством объекта M2M-связи. Другими словами, ETSI M2M SL-архитектура предоставляет стандарт на уровне услуг (SL) независимо от того, каков транспортный уровень/уровень доступа. Тем не менее, в настоящее время отсутствует архитектура поддержки согласно ETSI TS 102.69, которая четко задает "объединенные" версии или версии "для межсетевого взаимодействия" архитектур (сотового) транспортного уровня и уровня услуг (M2M) таким образом, чтобы давать возможность использования сотовой сети доступа для того, чтобы обеспечивать архитектуру общих M2M-услуг, которая главным образом подчиняется принципам ETSI M2M SL-архитектуры (указываемым в вышеуказанной ETSI TS 102.69), одновременно обеспечивая возможность сотовой сети доступа иметь надлежащее управление тем, для чего используется его сеть. Здесь, термин "общий" означает независимую от доступа природу такой M2M SL-архитектуры (т.е. общей SL-архитектуры, которая может функционировать во многих различных сетях доступа на основе IP, таких как, например, 3GPP, 3GPP2, стандарт долгосрочного развития (LTE), высокоскоростная система обмена пакетными данными (EV-DO), универсальная система мобильной связи (UMTS), стандарт форума по фиксированному доступу, общая служба пакетной радиопередачи (GPRS) и CDMA2000 1x-сети).

С другой стороны, даже если рабочая группа по разработке архитектур 3GPP-систем 2 (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, может разрешать использование своих транспортных услуг посредством M2M-услуг, когда сеть доступа не имеет соглашения об уровне обслуживания (SLA) с M2M SP.

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

Аналогично 3GPP SA2, 3GPP2 также нацелен на задание (например, в 3GPP2-отчете 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-приложений.

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

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

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

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

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

(c) Возможность для 3GPP-сети доступа корректно идентифицировать и привязывать IP-трафик, который поступает из различных M2M SP-сетей, к идентичному M2M-устройству доступа (например, M2M-устройству 56 доступа, показанному на фиг. 2).

(d) Возможность для 3GPP-сети доступа корректно находить досягаемость устройства M2M-услуг (например, устройства 58 M2M-услуг, показанного на фиг. 2) на основе трафика, который отправляется на конкретный идентификатор M2M-устройства А-Layers, в конкретные 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-устройства/шлюза А-Layers в ходе первого начального присоединения для получения услуг к SP-сети. Динамическое решение может быть предпочтительным, как упомянуто в вышеприведенной подчасти (a). Решение должно обеспечивать то, что идентификатор M2M D/G А-Layers, выполненный посредством M2M SP-сети, также является доступным для 3GPP-сети доступа и уникальным в 3GPP-сети доступа.

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

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

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

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

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

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

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

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

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

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

В другом варианте осуществления, настоящее раскрытие сущности направлено на улучшение конфигурации M2M-связи, которая основана на (a) разделении между транспортным уровнем, поддерживаемым посредством сотовой сети доступа, и уровнем услуг, поддерживаемым посредством M2M SP, и (b) использовании общих M2M SC для всех M2M-приложений. Улучшение содержит: развертывание M2M SC в сотовой сети доступа в качестве M2M SC-прокси-сервера, когда M2M SP развертывает M2M SC-сервер, и M2M SC-сервер не развертывается в сотовой сети доступа. M2M SC-прокси-сервер выполнен с возможностью выступать в качестве M2M SC-сервера в SP и ретранслировать связь в плоскости служебных сигналов между конкретными для объекта SC в объекте M2M-связи и M2M SC-сервером в M2M SP, при этом объект M2M-связи находится в состоянии беспроводной связи с сотовой сетью доступа и осуществляет доступ к M2M SP через сотовую сеть доступа. Улучшение также содержит совместное размещение IWKF в M2M SC-прокси-сервере, при этом IWKF выполнена с возможностью предоставлять интерфейс для межсетевого взаимодействия между сотовой сетью доступа и M2M SP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 13 предоставляет обзор примерных архитектурных случаев, которые рассматривают поддержку M2M-услуг для 3GPP-сети доступа;

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

ЧАСТЬ ОДИН

Фиг. 3 является общей архитектурой 60 поддержки M2M-услуг (для сотовой сети) согласно одному варианту осуществления настоящего раскрытия сущности, иллюстрирующей два различных возможных варианта архитектуры, которые обеспечивают возможность развертывания M2M SC 42, отдельных от M2M AS 62. Из вышеприведенного пояснения следует отметить, что такое отдельное развертывание может обеспечивать совместимость архитектуры 60 с требованиями ETSI M2M TC для соответствия M2M SL-архитектуры требованиям ETSI TS 102.69. Для простоты нижеприведенного пояснения, фиг. 3-8 классифицируются как составляющие «часть один» настоящего раскрытия сущности (которая поясняет общую архитектуру поддержки M2M-услуг для сотовых сетей доступа), тогда как фиг. 9-16 классифицируются как составляющие «часть два» настоящего раскрытия сущности (которая предоставляет примеры передачи служебных сигналов и другие сведения по реализации для архитектуры поддержки M2M-услуг части один в контексте 3GPP-сети доступа). Тем не менее разделение пояснения на такие различные части только служит для удобства, и такое разделение не должно быть истолковано как указывающие отсутствие непрерывности или отсутствие связанности между пояснениями в этих двух частях. Здесь следует отметить, что вследствие различных конфигураций сети, возможных в различных вариантах осуществления настоящего раскрытия сущности, различные сетевые элементы (в сотовой сети доступа и SP-сети), общие между фиг. 1 и 3 и имеющие, в общем, аналогичные функциональности, по-прежнему обозначаются посредством различных ссылок с номерами на фиг. 3, чтобы отличать их как реализованные в архитектуре 60, а также подчеркнуть то, что эти сетевые элементы на фиг. 3 могут быть надлежащим образом конфигурированы или модифицированы (в аппаратных средствах, через программное обеспечение или и то, и другое) (относительно своих эквивалентов на фиг. 1) с возможностью выполнять различные функциональности (пояснены подробнее ниже) согласно конкретным вариантам осуществления настоящего раскрытия сущности. Таким образом, на фиг. 3, только домен 34 M2M-устройств, линии 23A-23C радиосвязи, M2M SC 42 и пользовательское M2M-устройство 44 идентифицируются посредством идентичных ссылок с номерами так, как показано на фиг. 1. Тем не менее, "внутренние" сетевые элементы сотовой транспортной сети 64 (т.е. та часть сотовой сети доступа, которая предоставляет поддержку транспортного уровня для 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) могут представлять собой следующее: (a) Вариант 1. Сильносвязанная архитектура M2M-услуг (в которой M2M SC 42 находится в SP-сети, идентифицированной посредством ссылки с номером "82" и показанной пунктиром на фиг. 3). Этот вариант упоминается в качестве "варианта 1" (что означает первую конфигурацию сети или NT1) в нижней части фиг. 3. (b) Вариант 2. Слабосвязанная или распределенная архитектура M2M-услуг (в которой M2M SC 42 находится в сотовой сети доступа, идентифицированной посредством ссылки с номером "84" и также показанной пунктиром на фиг. 3). Этот вариант указывается в качестве "варианта 2" (что означает вторую конфигурацию сети или NT2) в нижней части фиг. 3. На фиг. 3, как SP-сеть 82, так и сотовая сеть 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). Следует понимать, что сотовая сеть 84 или 86 доступа (в зависимости от конкретной вышеуказанной конфигурации) может представлять собой сотовую телефонную сеть или наземную сеть мобильной связи общего пользования (PLMN), в которой M2M-устройства 24-32 (показаны на фиг. 1, но не показаны на фиг. 3 для простоты чертежа) могут представлять собой абонентские устройства. Кроме того, части сотовой сети 84 или 86 доступа могут включать в себя, независимо или в комбинации, любую из настоящих или будущих сетей проводной или беспроводной связи, таких как, например, PSTN, сеть на основе мультимедийной подсистемы на базе IP-протокола (IMS) или линия спутниковой связи. В конкретных вариантах осуществления, сеть 84 или 86 доступа может подключаться к Интернету через соединение своей базовой сети 78 с IP-сетью (с коммутацией пакетов) (не показана) или может включать в себя часть Интернета в качестве своей части. В одном варианте осуществления, сотовая сеть доступа может включать в себя большее или меньшее число либо другой тип функциональных объектов по сравнению с функциональными объектами, показанными в контексте сотовой сети 84 или 86 доступа на фиг. 3.

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

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

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

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

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

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

Здесь следует отметить, что текущие версии ETSI TS 102.69 и технического отчета (TR) 3GPP 23.888 (озаглавленного "System Improvements for Machine-Type Communications") не содержат пояснения такого совместного развертывания общих M2M SC 42 и соответствующей передачи служебных сигналов и архитектурных подробностей, в силу этого оставляя нерассмотренными определенные варианты развертывания и межсетевого взаимодействия (между сотовой сетью доступа и SP-сетью). Вариант осуществления на фиг. 4 рассматривает эту ситуацию без выхода за рамки принципов ETSI M2M TC (связанных с независимой от доступа M2M SL-архитектурой), упомянутых выше в разделе "Уровень техники" настоящего раскрытия сущности. Таким образом, в архитектуре 95 на фиг. 4, M2M SC оператора сотового доступа (т.е. общие M2M SC 42, развернутые в сотовой сети доступа) выступают в качестве M2M SC-прокси-сервера 100, который выполнен с возможностью ретранслировать всю связь в плоскости служебных сигналов между D/G-SC (постоянно размещающимися на соответствующих M2M-устройствах или шлюзах, работающих в домене 34 M2M-устройств, как упомянуто выше) и M2M SC-сервером 102 поставщика услуг. Не только он, но и M2M SC-прокси-сервер 100 также может быть выполнен с возможностью предоставлять оператору сотового доступа доступ ко всей информации по уровням, которая необходима для поддержки M2M-услуг в сотовой сети доступа. Использование M2M SC-прокси-сервера 100 может предоставлять множество дополнительных функциональностей, некоторые примеры которых приводятся ниже:

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

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

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

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

Фиг. 6 является примерной блок-схемой M2M SC-прокси-сервера (например, прокси-сервера 100, показанного на фиг. 4) согласно одному варианту осуществления настоящего раскрытия сущности. В одном варианте осуществления, M2M SC-прокси-сервер 100 может быть процессором данных или вычислительным модулем (например, компьютером общего назначения или PC, рабочей станцией и т.д.), который надлежащим образом конфигурируется (в аппаратных средствах и/или программном обеспечении) с возможностью выполнять различные функциональности прокси-сервера, поясненные в данном документе. В этом отношении прокси-сервер 100 может включать в себя модуль 112 обработки и управления (PCU), который может выполнять связанное с прокси-сервером приложение (программный или запрограммированный код), чтобы давать возможность прокси-серверу 100 предоставлять требуемую функциональность прокси-сервера (с использованием, например, механизма управления потоком обработки Java™) согласно идеям различных вариантов осуществления настоящего раскрытия сущности. M2M SC-прокси-сервер 100 также может включать в себя машиночитаемый носитель хранения данных (показан и упоминается в данном документе как "запоминающее устройство" 114 на фиг. 6), электрически соединенный с PCU 112. Запоминающее устройство 114 может содержать программный код (не показан), который при выполнении посредством PCU 112 может конфигурировать прокси-сервер 100 с возможностью предоставлять различные связанные с прокси-сервером функциональности, поясненные в данном документе. Таким образом, в пояснении в данном документе, хотя M2M SC-прокси-сервер 100 (или любой другой элемент или объект, показанный на фиг. 3-4 либо на аналогичных других чертежах, поясненных ниже) может упоминаться как "выполняющий", "осуществляющий" или "реализующий" (или другие термины, имеющие аналогичный смысл) функцию или процесс, специалистам в данной области техники должно быть очевидным, что это выполнение может технически осуществляться в аппаратных средствах и/или программном обеспечении требуемым образом. Оператор сети доступа или сторонний изготовитель/поставщик прокси-сервера 100 может надлежащим образом конфигурировать прокси-сервер 100 (например, через аппаратную и/или программную конфигурацию процессора 112) согласно конкретным требованиям оператора сети доступа.

Как показано на фиг. 6, в одном варианте осуществления, запоминающее устройство 114 в прокси-сервере 110 также может сохранять различную информацию 116 А-Layers (также взаимозаменяемо называемую "параметрами А-Layers") и обеспечивать доступность этой информации для PCU 112 при необходимости, чтобы помогать PCU 112 в предоставлении оператору сотовой сети доступа ко всей необходимой информации по уровням для поддержки M2M-услуг в сотовой сети 84 доступа. Как упомянуто выше, в одном варианте осуществления, параметры А-Layers представляют собой "внешний" идентификатор устройства/шлюза (такой как, например, вышеуказанный идентификатор M2M-устройства/шлюза А-Layers). В одном варианте осуществления, эти параметры А-Layers могут постоянно размещаться в M2M-устройстве/шлюзе, и прокси-сервер может извлекать их из M2M-устройства/шлюза. В варианте осуществления, в котором M2M-сервер (или другой аналогичный элемент) в SP-сети сохраняет эту информацию (которая также, возможно, извлечена из устройства/шлюза), прокси-сервер затем может принимать эту информацию из этого сервера. M2M SC-прокси-сервер 100 может взаимодействовать с сотовой CN 78 и SP-сетью 82 (более конкретно, M2M SC-сервером 102 в варианте осуществления по фиг. 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 может использовать распределенное хранение данных с/без избыточности.

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

РАЗДЕЛ 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-устройства/шлюза) (что подробнее поясняется в части два ниже в отношении 3GPP-сети доступа). Эта информация политик и подписок может быть статически конфигурирована (и сохранена, например, на M2M SC-прокси-сервере в гостевой сети доступа) или динамически передана (из релевантного поставщика услуг в гостевую сеть доступа) на основе предварительного согласования между M2M SP и оператором (гостевой) сети доступа. В этом случае, архитектура на основе прокси-сервера для соединения гостевой сотовой сети доступа с домашним M2M SP может быть аналогичной архитектуре, показанной на фиг. 4.

РАЗДЕЛ III: ПРИМЕРНЫЕ АРХИТЕКТУРНЫЕ СЛУЧАИ, КОТОРЫЕ РАССМАТРИВАЮТ ПОДДЕРЖКУ M2M-УСЛУГ ДЛЯ СОТОВОЙ СЕТИ ДОСТУПА

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

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

Случай 1: В этом случае, общие M2M SC (например, M2M SC 42 на фиг. 3) развертываются в M2M SP-сети 82 (фиг. 3) (например, в качестве M2M SP-сервера), в то время как сотовая сеть доступа (которая может иметь 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 SP-сети (т.е. сотовая сеть доступа может предоставлять транспортировку на уровень услуг (SP) выше себя, но без сведений в отношении того, что работает выше ее транспортного уровня). Такой вариант и не обеспечивает гибкость, и ни предоставляет множество вариантов выбора предложения M2M-услуг.

Случай 2: В этом случае, M2M SC 42 развертываются (в качестве M2M SC-сервера (не показан)) в сотовой сети 84 доступа (фиг. 3), при этом обслуживающий поставщик 88 M2M-услуг (который может иметь SLA с оператором сотовой сети доступа) не должен развертывать 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-сети, которая использует не-ETSI M2M SL-архитектуру. Оба из этих случаев предполагают SLA оператора сети доступа с M2M SP. Случай 3.1 рассматривает ситуацию, когда M2M SP поддерживает M2M SL-архитектуру, которая отличается от того, что указывается посредством ETSI (например, предпочитаемой ETSI архитектуры 10 на основе общих M2M SC на фиг. 1), и сотовая сеть доступа развертывает M2M SC (например, общие M2M SC 42 на фиг. 3) в качестве M2M SC-сервера. С учетом того, что случай 3.2 связан с ситуацией, когда сеть доступа не развертывает M2M SC (т.е. сеть доступа не имеет M2M SC-сервера, аналогично случаю 3.1), но SP-сеть по-прежнему поддерживает не-ETSI M2M SL-архитектуру.

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

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

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

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

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

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

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

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

РАЗДЕЛ IV: ПРИМЕРНЫЕ ВАРИАНТЫ ОСУЩЕСТВЛЕНИЯ ПОДДЕРЖКИ M2M-УСЛУГ ПОСРЕДСТВОМ СОТОВОЙ СЕТИ ДОСТУПА СОГЛАСНО ИДЕЯМ НАСТОЯЩЕГО РАСКРЫТИЯ СУЩНОСТИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЧАСТЬ ДВА

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

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

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

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

РАЗДЕЛ 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-объекте в конкретном варианте осуществления) и может идентифицировать то, используется (либо сконфигурировано/авторизовано) M2M-устройство 162 доступа объекта (фиг. 9) только для M2M-услуг, для M2M и регулярного доступа в Интернет, только для регулярного доступа в Интернет или для любой другой комбинации. Если 3GPP/3GPP2-сеть идентифицирует то, что подписка для доступа предназначена для предоставления соединения для доступа и транспортного соединения для M2M-объекта, один вариант осуществления настоящего раскрытия сущности предполагает, что следующие параметры сконфигурированы как часть профиля подписки для доступа объекта (например, в сети доступа) в дополнение к другим уже существующим стандартным параметрам:

(i) Имя точки доступа (APN) возможностей услуг M2M-сети доступа (N-SC) по умолчанию. N-SC APN идентифицирует N-SC и возможности подключения к ним. Таким образом, M2M N-SC APN сети доступа по умолчанию может идентифицировать M2M SC 3GPP-сети доступа по умолчанию, которые могут использоваться для начального присоединения для получения услуг (пояснено ниже) и для инициализации M2M-объекта согласно M2M SP в расчете на вариант выбора. Вследствие частых пояснений сетевых SC и SC на основе устройства/шлюза в этой части два, термин "N-SC" используется для того, чтобы отличать сетевые SC (будь то в сети доступа и/или в 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-устройства/шлюза А-Layers. Это может осуществляться посредством только поставщика M2M-услуг через координацию между поставщиком M2M-услуг и оператором сети доступа и/или посредством некоторого другого объекта (например, изготовителя M2M-устройств/шлюзов), который доверен посредством поставщика M2M-услуг и/или оператора сети доступа.

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

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

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

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

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

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

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

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

(iii) Инициализация M2M-объекта (как подробнее поясняется, например, в разделе V ниже) и последующее сообщение в сеть доступа сведений по конкретным для объекта параметрам А-Layers, включающим в себя, например, идентификатор M2M-устройства/шлюза А-Layers.

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

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

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

РАЗДЕЛ V: ПОДРОБНОСТИ ПЕРВОГО НАЧАЛЬНОГО ПРИСОЕДИНЕНИЯ И ПОСЛЕДУЮЩЕГО РЕГУЛЯРНОГО ПРИСОЕДИНЕНИЯ К SP-СЕТИ M2M-ОБЪЕКТА

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

ПОДРАЗДЕЛ V(A): ПЕРВОЕ НАЧАЛЬНОЕ ПРИСОЕДИНЕНИЕ К SP-СЕТИ M2M-ОБЪЕКТА

Фиг. 11 показывает примерную сетевую архитектуру 190, иллюстрирующую использование M2M N-SC 192 на основе сети доступа по умолчанию в ходе начального присоединения к SP-сети M2M-объекта согласно одному варианту осуществления решения по поддержке M2M-услуг для 3GPP-доступа (или других доступов, которые используют 3GPP EPC, таких как, например, CDMA2000 eHRPD). M2M-объект может быть любым из объектов 24-32 M2M-связи, работающих в домене 34 M2M-устройств, как проиллюстрировано на фиг. 1. Как упомянуто выше (например, со ссылкой на фиг. 4 и 8A-8B), для простоты пояснения и контекста, аналогичные ссылки с номерами используются для функционально аналогичных сетевых элементов/компонентов (например, транзитного соединения, базовой сети, 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, 8A-8B и 11-12 служит просто для того, чтобы предоставлять удобную контекстную ссылку и иллюстрировать сходства между архитектурами на фиг. 3 и на других чертежах, т.е. то, как архитектуры на фиг. 4, 8A-8B и 11-12 основаны на общей архитектуре на фиг. 3; это не обязательно подразумевает, что архитектуры на фиг. 3-4, 8A-8B и 11-12 являются идентичными или практически аналогичными во всех аспектах без каких-либо отличий.

Аналогично другим чертежам, дополнительные подробности вышеприведенных сетевых элементов/компонентов не повторяются в данном документе для краткости. Тем не менее, следует отметить, что в конфигурации 190 на фиг. 11, 3GPP-сеть 84 доступа развертывает общие 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 в сети 84 доступа; наоборот, идентичные M2M SC (например, общие M2M SC 42 на фиг. 3) могут быть развернуты в сети 84 доступа с различными функциональностями - в качестве 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 развертываются в обеих сетях, т.е. в 3GPP-сети 84 доступа (например, в качестве M2M SC-прокси-сервера), а также в M2M SP-сети 82 (например, в качестве M2M SC-сервера), общая архитектурная конфигурация на фиг. 3 может быть аналогичной архитектурной конфигурации, показанной на фиг. 4.

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

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

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

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

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

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

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

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

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

(7) Помимо этого, M2M N-SC 192 сети доступа по умолчанию могут обмениваться данными с репозиторием профилей абонентов (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-подпиской для доступа, параметров А-Layers и всех остальных параметров, M2M-объект может перезагружаться или повторно присоединяться к SP-сети в расчете на вариант выбора для осуществления всех изменений инициализации. Это означает, в одном варианте осуществления, что M2M-объект может выполнять регулярное присоединение (в качестве части перезагрузки или повторного присоединения), как представлено ниже.

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

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

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

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

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

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

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

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

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

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

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

РАЗДЕЛ VI: ПРИМЕРНЫЕ АРХИТЕКТУРНЫЕ СЛУЧАИ ДЛЯ РЕШЕНИЯ ПО ПОДДЕРЖКЕ 3GPP M2M-УСЛУГ

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

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

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

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

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

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

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

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

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

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

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

После того, как M2M-объект завершает процедуру регистрации при начальном присоединении, D/G-SC могут выполнять обновление начальной SL-регистрации с помощью M2M N-SC сети доступа по умолчанию. На этом этапе, D/G-SC могут предоставлять необходимую информацию (А-Layers) в M2M N-SC сети доступа по умолчанию, чтобы выполнять обновление M2M-подписки для доступа (MASU). Это MASU может включать в себя обновление M2M N-SC сети доступа по умолчанию, например, (домашней) 3GPP-сети доступа с помощью M2M N-SC APN регулярной сети доступа, которая указывает на надлежащий 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 сети доступа по умолчанию (с помощью необходимой информации А-Layers) после завершения этапов первой начальной регистрации для получения услуг, но до этого SP N-SC отправляют успешное выполнение начальной регистрации в D/G-SC.

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

M2M N-SC сети доступа по умолчанию затем могут выполнять MASU-процедуру, поясненную выше. После успешного выполнения MASU-процедуры M2M N-SC сети доступа по умолчанию могут указывать успешное выполнение в SP N-SC (а не в D/G-SC, как в варианте 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 не могут иметь доступа или авторизации на использование функциональности прокси-сервера в сети доступа, как упомянуто выше.

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

РАЗДЕЛ VII: ПРИМЕРНЫЕ ВЫСОКОУРОВНЕВЫЕ ПОСЛЕДОВАТЕЛЬНОСТИ ОПЕРАЦИЙ ОБРАБОТКИ

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

Фиг. 14 иллюстрирует примерные высокоуровневые последовательности операций обработки согласно одному варианту осуществления настоящего раскрытия сущности для начального присоединения M2M-объекта (например, M2M-объекта 155 на фиг. 9) к M2M SP в расчете на вариант выбора (например, M2M SP 82 на фиг. 11) через 3GPP-сеть доступа (например, 3GPP-сеть 84 доступа на фиг. 11). Здесь следует отметить, что вследствие N-SC-развертывания в SP-сети на фиг. 14-16, эти чертежи могут считаться представляющими архитектуру поддержки M2M-услуг на фиг. 11. Тем не менее, подробности базовой 3GPP-сети 78 на фиг. 11 предоставляются на фиг. 12, который показывает различные компоненты/элементы (например, MME, PCRF и т.д.) базовой сети 78. Следовательно, для простоты пояснения, фиг. 14-16 трактуются как "комбинация" фиг. 11 и 12, так что идентичные ссылки с номерами из фиг. 11-12 могут быть использованы для того, чтобы идентифицировать компоненты/элементы на фиг. 14-16, имеющие идентичную или аналогичную функциональность. За исключением eNB 219 и обслуживающего шлюза 145 (SGW) на фиг. 14-16, все остальные компоненты сети доступа на фиг. 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 3GPP-сети доступа, как указано на этапе 221. Этот запрос на начальное присоединение может включать в себя IMSI устройства 162 доступа (здесь, "IMSI1", как упомянуто выше). В варианте осуществления по фиг. 14, устройство 162 доступа не конфигурируется предварительно с помощью M2M N-SC 3GPP -сети доступа по умолчанию. Следовательно, запрос на начальное присоединение на этапе 221 не включает в себя APN (например, запрос может отправляться с нулевой APN). При приеме запроса на начальное присоединение MME 200 может осуществлять выборку профиля AN-подписки этого M2M-устройства доступа (т.е. профиля M2M-подписки для доступа, поясненного в разделе I этой части два) и другой релевантной информации (например, ключей аутентификации устройств) из HSS 142 на основе IMSI1, выделяемого этому устройству, как указано на этапе 222. MME 200 принимает APN M2M N-SC 192 сети доступа по умолчанию в качестве части этого профиля AN-подписки. Устройство 162 доступа может ожидать аутентификации доступа (этап 223), в то время как MME 200 использует M2M N-SC APN сети доступа по умолчанию, чтобы создавать сеанс в надлежащем SGW 145 и надлежащем P-GW 147, как указано на этапах 224-225. После создания требуемых сеансов в SGW и P-GW, MME 200 может сообщать успешное выполнение AN-присоединения в устройство доступа, а также назначать ему IP-адрес на этапе 226. M2M-объект 155 затем может пытаться устанавливать PDN-подключение к M2M N-SC 192 сети доступа по умолчанию (этап 227) через P-GW 147 (этап 228). В варианте осуществления по фиг. 14, устройство доступа может устанавливать соединение для передачи служебных M2M SL-сигналов (этап 229) с M2M N-SC 192 сети доступа по умолчанию, чтобы упрощать передачу служебных 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 сети доступа по умолчанию идентифицировать M2M SP 82 в расчете на вариант выбора M2M-объекта и релевантное SLA между оператором 3GPP-сети доступа и M2M SP, а также идентифицировать архитектуру поддержки M2M-услуг, поддерживаемую посредством M2M SP-сети, на основе SLA (этап 232). M2M N-SC 192 сети доступа по умолчанию затем могут запрашивать начальную SL-регистрацию M2M-объекта 155 в M2M SP 82 в расчете на вариант выбора на этапе 233. На этапе 233, N-SC 192 сети доступа по умолчанию могут предоставлять идентификатор подписки на M2M-услуги M2M-объекта и идентификатор D/G-SC в M2M SP N-SC 194 (которые могут быть развернуты в качестве M2M SP N-SC-сервера) и могут запрашивать идентификатор M2M D/G А-Layers и другие параметры из M2M SP N-SC 194. После того, как SP-сеть 82 выделяет необходимый идентификатор M2M D/G А-Layers (этап 234), M2M SP N-SC 194 могут подтверждать запрос на начальную SL-регистрацию (на этапе 233) и предоставлять необходимый идентификатор А-Layers в M2M N-SC 192 сети доступа по умолчанию на этапе 235. В ответ, на этапе 236, N-SC 192 сети доступа по умолчанию могут обновлять профиль AN-подписки M2M-устройства доступа в HSS 142 с помощью идентификатора D/G А-Layers и, возможно, с помощью APN релевантных регулярных M2M N-SC на основе сети доступа, чтобы упрощать будущее регулярное присоединение M2M-объекта 155 к M2M SP 82 в расчете на вариант выбора. Как упомянуто выше, в одном варианте осуществления, M2M N-SC на основе сети доступа по умолчанию также могут выступать в качестве регулярных M2M N-SC для данного M2M-объекта и M2M SP в расчете на вариант выбора. На этапе 237, успешное выполнение начального присоединения подтверждается посредством M2M N-SC 192 сети доступа по умолчанию, которые также назначают M2M-объекту 155 APN M2M N-SC регулярной сети доступа для будущего регулярного присоединения. M2M-объект 155 затем может выполнять регулярное присоединение к SP-сети (этап 238), как пояснено ниже со ссылкой на фиг. 15-16.

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

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

РАЗДЕЛ VIII: КАК 3GPP-СЕТЬ ДОСТУПА РАЗЛИЧАЕТ МЕЖДУ НАЧАЛЬНЫМ ПРИСОЕДИНЕНИЕМ ДЛЯ ПОЛУЧЕНИЯ УСЛУГ И РЕГУЛЯРНЫМ ПРИСОЕДИНЕНИЕМ

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

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

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

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

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

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

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

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

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

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

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

(4) MME может использовать M2M N-SC APN сети доступа по умолчанию, чтобы создавать сеанс в надлежащем SGW и надлежащем P-GW.

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

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

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

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

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

(4) MME затем может использовать M2M N-SC APN регулярной сети доступа, чтобы создавать сеанс с надлежащим SGW и надлежащим P-GW.

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

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

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

(3) MME может осуществлять выборку профиля подписки для доступа M2M-объекта из HSS в числе другой информации. Поскольку HSS имеет выполненные M2M N-SC APN сети доступа по умолчанию и M2M N-SC APN регулярной сети доступа (см. этап (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-сети доступа), которая соответствует требованиям ETSI M2M SL-архитектуры с достаточной степенью свободы (для оператора 3GPP-сети доступа) для варианта выбора поставщика M2M-услуг при обеспечении того, что оператор 3GPP-сети доступа имеет полное управление над своей сетью и имеет динамически совместно использовать информацию M2M-устройств/шлюзов по уровням с M2M SP.

Вариант 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-сети доступа имеет исчерпывающие сведения по такой динамической конфигурации и имеет доступ к релевантной информации А-Layers.

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

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

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

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

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

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

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

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

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

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

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

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

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

(d) Предоставляют динамическое решение для обновления профиля политик абонентов M2M-доступа с PCRF с использованием динамически выделяемого идентификатора M2M D/G А-Layers и M2M-приложений и ассоциированного QoS.

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