Архитектура поддержки м2м-услуг для сотовых сетей доступа

Архитектура поддержки м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 в своей сети без необходимости поддерживать различные интерфейсы для меж