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

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

[0001] Данная заявка связана с предварительной заявкой на патент США №62/359,508, поданной 7 июля 2016 года, по которой испрашивается приоритет и содержание которой целиком включено в состав настоящей заявки посредством ссылки.

ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ ОБЛАСТЬ ТЕХНИКИ

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

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

[0003] В рамках проекта совместной координации разработки систем третьего поколения (3GPP) начиная с версии 11 (Rel-11) определена связь машинного типа (МТС, Machine Type Communication) с использованием услуги передачи мобильных входящих коротких сообщений (MT-SMS, Mobile Terminating (МТ) Short Messaging Service (SMS)) без применения телефонного номера мобильной станции, также называемого международным телефонным номером абонента мобильной станции (MSISDN, Mobile Station International Subscriber Directory Number). Эта технология определена в технической спецификации (TS, Technical Specification) 23.682 3GPP.

[0004] Основной принцип МТС согласно Rel-11 состоит в том, что сторонний сервер приложений услуги может отправлять или передавать небольшой объем данных в устройство, например в пользовательское оборудование (UE, User Equipment), с помощью назначенного оператором внешнего идентификатора (например, <device_id>@Operator_Domain_ID) через стандартизованный интерфейс (например, Tsp) с сетью оператора. Затем сеть оператора транслирует этот внешний идентификатор в международный идентификатор мобильного абонента UE (IMSI, International Mobile Subscriber Identity) и использует MT-SMS для переноса полезной нагрузки приложения в UE. Если UE требуется ответить стороннему серверу приложений, то ожидается, что UE для связи может установить сеанс в сети доступа с возможностью соединения по Интернет-протоколу (IP-CAN, Internet Protocol (IP) Connectivity Access Network) со сторонним сервером приложений. Таким образом, предполагалось, что MT-SMS и установление сеанса IP-CAN достаточно для МТС в Rel-11.

[0005] Исходящая мобильная (МО, Mobile Originated) услуга SMS без MSISDN возможна только для UE с мультимедийной IP-подсистемой (IMS, IP Multimedia Subsystem), что требует новых возможностей IMS UE, описанных в TS 23.204 3GPP. Сетевое взаимодействие с UE, не поддерживающим SMS без MSISDN, основано на реализации оператора. Таким образом, в настоящий момент отсутствует определенный стандарт 3GPP, позволяющий обслуживающему узлу принимать и пересылать MO-SMS из IMS UE, которому не назначен MSISDN. Обычно обслуживающий узел получает информацию о MSISDN UE из данных подписки, принимаемых из опорного абонентского сервера (HSS, Home Subscriber Server). Таким образом, обслуживающий UE узел вставляет MSISDN UE в MO-SMS, для того чтобы MSISDN мог использоваться в качестве доверенного идентификатора получателем короткого сообщения.

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

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

[0007] Как вариант, приложение может включать приложение связи машинного типа.

[0008] Как вариант, идентификация может включать установку заранее заданного значения в качестве идентификатора порта приложения.

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

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

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

[0012] Как вариант, способ может также включать передачу сообщения из пользовательского оборудования.

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

[0014] Как вариант, приложение может включать приложение связи машинного типа.

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

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

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

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

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

[0020] Как вариант, запрос может содержать запрос опорного абонентского сервера.

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

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

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

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

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

[0026] Согласно одиннадцатому и двенадцатому вариантам осуществления настоящего изобретения система может содержать по меньшей мере одно устройство, соответствующее третьему или пятому вариантам осуществления и взаимодействующее по меньшей мере с одним устройством, соответствующим четвертому или шестому вариантам осуществления, соответственно, во всех их реализациях.

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

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

[0028] На фиг. 1 показана архитектура МТС.

[0029] На фиг. 2 показана передача MO-SMS через SMS-SC в соответствии с определенными вариантами осуществления настоящего изобретения.

[0030] На фиг. 3 показана передача MO-SMS непосредственно в MTC-IWF в соответствии с определенными вариантами осуществления настоящего изобретения.

[0031] На фиг. 4 показан алгоритм выполнения способа в соответствии с определенными вариантами осуществления настоящего изобретения.

[0032] На фиг. 5 показана блок-схема системы в соответствии с определенными вариантами осуществления настоящего изобретения.

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

[0033] В определенных случаях UE может потребоваться передача подтверждения в сервер приложений. В подтверждении может передаваться небольшая полезная нагрузка. Подтверждение может передаваться после приема UE сообщения MT-SMS. Установление сеанса IP-CAN для передачи небольшой полезной нагрузки может быть достаточно расточительным, поскольку при этом для такой небольшой нагрузки может создаваться большой объем данных сигнализации с целью установления и разъединения сеанса IP-CAN.

[0034] В версии Rel-13 3GPP определено MO-SMS из UE для адресации такого подтверждения, переносящего небольшую полезную нагрузку, с использованием функции представления возможностей услуг (SCEF, Service Capability Exposure Function). Однако оператор может посчитать нецелесообразным обновление своей сетевой архитектуры МТС для подключения такой функции Rel-13 как SCEF.

[0035] Оператор может поддерживать очень стабильную/крупномасштабную инфраструктуру SMS и может предпочитать, чтобы UE использовало MO-SMS для передачи подтверждения в сервер приложений. Однако обычно для этого может потребоваться, чтобы UE использовало MSISDN в соответствии с требованиями стандарта/протокола SMS, определенного в TS 23.040 3GPP.

[0036] В определенных вариантах осуществления, UE, которому не назначен MSISDN, может разрешаться передача MO-SMS. Такое MO-SMS может перемещаться в домене оператора и доставляться в сторонний сервер приложений через Tsp-интерфейс.Кроме того, полезная нагрузка, поступающая через Tsp, может удостоверяться сторонним сервером приложений. В определенных вариантах осуществления IMSI UE может предоставляться серверу приложений, а может быть скрыт.Однако в определенных вариантах осуществления может применяться способ обратного преобразования IMSI во внешний идентификатор.

[0037] Таким образом, в определенных вариантах осуществления предоставляется возможность передачи MO-SMS без MSISDN. В определенных вариантах осуществления обеспечиваются альтернативные идентификаторы, которые могут быть использованы. Кроме того, в определенных вариантах осуществления реализуются способы сквозной передачи и/или преобразования MO-SMS без MSISDN.

[0038] На фиг. 1 показана архитектура МТС. Более конкретно, на фиг. 1 показана архитектура МТС, определенная в TS 23.682 3GPP. На чертеже показаны две специально помеченные линии: "Маршрут для MT-SMS" и "Маршрут для MO-SMS". Посредством маршрута для MT-SMS показан маршрут сигнализации, задействованный с использованием процедуры MT-SMS/T4 в соответствии с TS 23.682 3GPP. Маршрут MO-SMS показан для одного из двух подходов, обсуждаемых ниже. Этот маршрут может быть подобен маршруту для MT-SMS/T4. Маршрут сигнализации MO-SMS для другого из двух подходов, обсуждающихся ниже, может обходить SMS-SC.

[0039] Таким образом, на фиг. 1 с целью иллюстрации показаны маршруты сигнализации MT-SMS и MO-SMS с использованием передачи MO-SMS посредством решения SMS over SGs (передача SMS через SG). MO-SMS также может также непосредственно поступать из ММЕ в SMS-SC через SGd, но этот маршрут не показан на фиг. 1.

[0040] Для MT-SMS MTC-IWF может выполнять запрос HSS перед передачей сообщения в SMS-SC. Таким же образом, в случае первого подхода для MO-SMS центр SMS-SC может выполнять запрос HSS перед передачей сообщения в MTC-IWF. Помимо этого, в рамках обоих описываемых ниже подходов для MO-SMS MTC-IWF может выполнять запрос HSS перед передачей сообщения в SSC.

[0041] На фиг. 2 показана передача MO-SMS через SMS-SC в соответствии с определенными вариантами осуществления настоящего изобретения. Для удобства этот алгоритм может называться первым подходом. Далее в соответствии с первым подходом описываются некоторые типовые процедуры, которые могут быть выполнены таким образом, как показано на фиг. 2.

[0042] Как описано в TS 23.012 3GPP, в разделе 3.6.1.5, HSS не содержит MSISDN для этого UE. Обслуживающий узел, в данном случае MSC/реестр местоположения посетителей (VLR, Visitor Location Register), может затем использовать фиктивное значение MSISDN, сконфигурированное в обслуживающем узле для этого UE. Соответственно, обслуживающий узел, например MSC/VLR, может быть сконфигурирован для поддержки функционирования в отсутствие MSISDN. В альтернативном варианте UE может быть назначен фиктивный MSISDN в записи о подписке, например, в HSS/опорном реестре местоположения (HLR, Home Location Register). Всем МТС UE может назначаться одинаковый фиктивный MSISDN. Этот фиктивный MSISDN может обеспечивать обратную совместимость в протоколе SMS-MO в MSC.

[0043] Серверу приложений может быть назначен фактический MSISDN, например, в формате Е. 164. Оборудование UE может передавать MO-SMS по этому номеру.

[0044] Если приложению МТС UE назначено множество "внешних идентификаторов", то для определения, какой "внешний идентификатор" является идентификатором объекта передачи, UE может использовать несколько следующих альтернативных вариантов.

[0045] В соответствии с первым вариантом UE может присвоить идентификатору порта приложения в протоколе SMS определенное стандартное значение. Диапазон этого значения может составлять до 255 для 8-битной адресации и до 65535 для 16-битной адресации.

[0046] Затем узел, выполняющий функцию сетевого взаимодействия МТС (MTC-IWF, МТС InterWorking Function), может запросить у HSS идентификатор IMSI и принятый адрес порта приложения, для того чтобы получить соответствующий внешний идентификатор. Это может потребовать наличия в HSS и UE одинаковой таблицы преобразования. Например, HSS и UE могут содержать одинаковую таблицу преобразования между IMSI+идентификатором порта приложения и внешним идентификатором.

[0047] В соответствии со вторым вариантом UE может кодировать внешний ID как часть полезной нагрузки SMS. В этом случае сервер приложений может определять идентификатор объекта передачи путем просмотра полезной нагрузки. В этом варианте, в отличие от первого варианта, можно исключить объявление сетью идентификатора UE. Таким образом, в этом варианте может быть задействовано предоставление сетью IMSI для сервера приложений с целью обеспечения жизнеспособности такого подхода.

[0048] В соответствии с третьим вариантом, не предусматривающим предоставление IMSI серверу приложений, сеть может указать серверу приложений IP-адрес, назначенный UE. При этом также может выполняться кодирование UE своего собственного IP-адреса в полезной нагрузке SMS. Затем сервер приложений может проверить оба IP-адреса для определения, переносит ли отправитель назначенный IP-адрес, для обеспечения некоторого уровня проверки целостности. Однако этот вариант может не работать, если UE не имеет IP-адреса.

[0049] В соответствии с четвертым вариантом сервер приложений и UE могут использовать общий секретный ключ в полезной нагрузке SMS для объявления UE идентификатора отправителя. Этот процесс может быть основан на требовании прикладного уровня.

[0050] Первый вариант проиллюстрирован на фиг. 2. Подобным образом могут быть реализованы и другие варианты.

[0051] Как показано на фиг. 2, на шаге 1 UE может выполнить процедуру комбинированного присоединения для передачи МО SMS с использованием решения "МО SMS via SMS over interface SGs" (передача SMS по интерфейсным SG), определенного в TS 23.272 3GPP. Фиктивный MSISDN может назначаться этому UE из опорной наземной сети мобильной связи общего пользования (HPLMN, Home Public Land Mobile Network). Этот фиктивный MSISDN может сохраняться в VLR.

[0052] Если MSC/VLR и HSS поддерживают функционирование в отсутствие MSISDN, как определено в TS 23.012 3GPP, в разделе 3.6.1.5, то в таком случае MSC/VLR может назначить фиктивный MSISDN для этого UE.

[0053] На шаге 2 UE может передать МО SMS. Это сообщение может содержать адрес SMS-SC в виде адреса центра обслуживания в сообщении отправки SMS. Адрес получателя может быть установлен равным MSISDN сервера приложений МТС.UE может указать внешний идентификатор, который UE желает использовать, путем установки соответствующего значения идентификатора порта приложения в информационном элементе Addressing (адресация) поля данных TP-user (TP-пользователь). Более подробная информация о полях сообщения представлена, например, bTS 23.040 3GPP.

[0054] На шаге 3 MSC/VLR может выполнить размещение фиктивного MSISDN и IMSI UE как часть процедуры в ходе операции 'MAP МО forward SM' (пересылка исходящего короткого сообщения по протоколу MAP). Более подробно эта процедура описывается, например, в TS 29.002 3GPP. RP-DA может содержать адрес SMS-SC, предоставленный UE.

[0055] На шаге 4а шлюзовый коммутационный центр мобильной связи (GMSC, Gateway Mobile Switching Center) SMS-SC может запросить HSS/HLR с использованием MSISDN из поля TP-DA, например сервер приложений МТС.Также может добавляться индикация Т4. Индикатор Т4 может гарантировать, что HSS/HLR не пересылает сообщение MAP в IP-SM-GW. Этот процесс может быть основан на процедуре, описанной в TS 29.002 3GPP. На шаге 4b HSS/HLR может возвратить МТС-IWF/SCEF в качестве обслуживающего узла. Этот процесс может быть основан на конфигурации HSS/HLR.

[0056] Обычно в протоколе MAP может потребоваться, чтобы HSS/HLR возвращал IMSI номера MSISDN. Однако этот IMSI может оказаться лишним, поскольку этот IMSI может указывать на MSISDN сервера приложений МТС.Таким образом, HSS/HLR может назначить фиктивный IMSI в этом протоколе MAP.

[0057] На шаге 5 SMS-SC может переслать MT-SMS в MTC-IWF/SCEF. Адрес MTC-IWF/SCEF может приниматься на шаге 4b, как описано выше. Вместо записи IMSI MSISDN сервера МТС в поле RP-DA центр SMS-SC может записать в поле RP-DA идентификатор IMSI UE. В альтернативном варианте для передачи этих данных SMS-SC может записать IMSI UE в новый информационный элемент.

[0058] SMS-SC может быть осведомлен об этой специальной процедуре на основе любого из следующего. IMSI или фиктивному IMSI, возвращаемому на шаге 4b, может быть присвоено конкретное значение в качестве индикатора. В альтернативном варианте фиктивному MSISDN может быть присвоено конкретное значение в качестве индикатора. В другом альтернативном варианте индикатором может служить MSISDN сервера МТС. В еще одном альтернативном варианте на шаге 4b HLR/HSS может предоставить новый информационный элемент (IE, Information Element) в качестве индикатора.

[0059] На шаге 6 MTC-IWF/SCEF может использовать IMSI UE и идентификатор порта приложения для запроса у HSS/HLR внешнего идентификатора UE. Если IMSI может быть предоставлен и внешний идентификатор не используется, этот шаг может быть опущен.

[0060] На шаге 7 MTC-IWF/SCEF может переслать полезную нагрузку SMS в сервер приложений МТС совместно с внешним идентификатором, запрошенным у HSS/HLR, или IMSI, если IMSI может быть предоставлен.

[0061] На фиг. 3 показана передача MO-SMS непосредственно в MTC-IWF в соответствии с определенными вариантами осуществления настоящего изобретения. Для удобства этот алгоритм может называться вторым подходом. Далее в соответствии со вторым подходом описываются некоторые типовые процедуры, которые могут быть выполнены, как показано на фиг. 3.

[0062] Этот второй подход можно рассматривать как оптимизацию представленного выше решения в результате разрешения обхода SMS-SC при передаче MO-SMS. Этот процесс может быть выполнен путем конфигурирования в UE адреса MTC-IWF в качестве адреса центра обслуживания SMS.

[0063] Ряд функций, показанных на фиг. 3, выполняется аналогично соответствующим функциям, показанным на фиг. 2. Например, функции, выполняемые на шаге 1, аналогичны на обоих чертежах. Кроме того, функции, выполняемые на шагах 4 и 5, изображенных на фиг. 3, могут быть аналогичны функциям, выполняемым на шагах 6 и 7, показанным на фиг. 2.

[0064] Функции, выполняемые на шаге 2, аналогичны функциям, выполняемым на шаге 2, изображенном на фиг. 2, за исключением того, что адрес MTC-IWF в виде MSISDN может использоваться как адрес центра обслуживания в сообщении представления SMS. Функции, выполняемые на шаге 3, могут быть аналогичны функциям, выполняемым на шаге 3, изображенном на фиг. 2, за исключением того, что RP-DA может содержать адрес MTC-IWF. Этот адрес может инициировать маршрутизацию сообщения транспортной сетью непосредственно в MTC-IWF.

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

[0066] Основное различие между двумя подходами состоит в маршруте сигнализации, используемом для передачи SMS-сообщения. Согласно первому подходу SMS передается через SMSC и IWF, в то время как в соответствии со вторым подходом осуществляется обход SMSC.

[0067] Более конкретно, в соответствии с первым подходом может потребоваться конфигурирование MTC-IWF для приема MAP-MT-FSM. В отличие от этого, согласно второму подходу может потребоваться конфигурирование MTC-IWF для приема MAP-MO-FSM.

[0068] В соответствии с первым подходом MTC-IWF может быть доступен с использованием адреса обслуживающего узла, возвращаемого HSS. Он может быть изменен в HSS. В отличие от этого, согласно второму подходу MTC-IWF может быть доступен с использованием адреса MTC-IWF, сконфигурированного для UE в качестве адреса центра обслуживания. Он может быть изменен UE, например, с помощью MMI пользовательского интерфейса.

[0069] Согласно первому подходу сохранение и пересылка, а также учет стоимости при необходимости может выполняться с использованием SMS-SC. В соответствии со вторым подходом SMS-SC не играет роли для MO-SMS, и следовательно, сохранение и пересылка, а также учет стоимости не может выполняться с использованием SMS-SC.

[0070] Согласно первому подходу маршруты МТ и МО могут быть симметричными. В пределах маршрута МО может использоваться один запрос HSS, в то время как в пределах маршрута МТ могут использоваться два запроса HSS. В соответствии со вторым подходом маршруты МТ и МО могут быть не симметричными. Однако благодаря такой асимметрии можно сэкономить данные сетевой сигнализации, передаваемые в HSS. Например, согласно второму подходу маршрут МТ может проходить из AS в SCS, в MTC-IWF (запрос HSS), в SMS-SC, в MSC, в ММЕ, в UE. Маршрут МО может проходить из UE, в ММЕ, в MSC, в MTC-IWF (запрос HSS), в SCS-AS.

[0071] Функциональное воздействие, оказываемое первым подходом, может быть существеннее по сравнению со вторым подходом. Например, в определенных вариантах осуществления может потребоваться дополнить MO-FSM идентификатором порта приложения, и в определенных вариантах осуществления может использоваться запрос HSS для получения внешнего идентификатора с использованием IMSI и идентификатора порта приложения.

[0072] На фиг. 4 показан алгоритм выполнения способа в соответствии с определенными вариантами осуществления настоящего изобретения. Как показано на фиг. 4, способ на шаге 410 может включать подготовку в пользовательском оборудовании исходящего мобильного сообщения услуги передачи коротких сообщений. Способ на шаге 420 может также включать идентификацию в сообщении конкретного внешнего идентификатора из набора внешних идентификаторов, назначенных приложению. Приложение может представлять собой приложение связи машинного типа.

[0073] Идентификация может включать установку заранее заданного значения в качестве идентификатора порта приложения. Этот или любые последующие варианты могут упростить для принимающего сетевого элемента идентификацию внешнего идентификатора, соответствующего передающему объекту, как указывалось выше.

[0074] Идентификация может включать кодирование конкретного внешнего идентификатора в виде части полезной нагрузки сообщения. В альтернативном варианте или дополнительно, идентификация может включать кодирование адреса Интернет-протокола, назначенного пользовательскому оборудованию, в виде части полезной нагрузки сообщения. В альтернативном варианте или дополнительно, идентификация может включать кодирование общего секретного ключа в виде части полезной нагрузки сообщения.

[0075] Способ на шаге 430 может также включать передачу сообщения из пользовательского оборудования. Это сообщение далее может быть принято, обработано и переслано в сеть.

[0076] Указанные выше шаги могут выполняться пользовательским оборудованием. Описываемые ниже шаги могут выполняться сетевым элементом, таким как MTC-IWF.

[0077] Способ на шаге 440 может включать прием в сетевом элементе исходящего мобильного сообщения услуги передачи коротких сообщений. Это может быть то же самое сообщение, что передано на шаге 430, или сообщение, основанное на этом сообщении, как различным образом проиллюстрировано на фиг. 2 и 3.

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

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

[0080] Способ может также на шаге 455 включать преобразование между внешним идентификатором и информацией в сообщении с использованием запроса. Запрос может представлять собой запрос опорного абонентского сервера.

[0081] Способ на шаге 460 может также включать пересылку сообщения на основе конкретного внешнего идентификатора.

[0082] На фиг. 5 показана система, соответствующая определенным вариантам осуществления настоящего изобретения. Следует понимать, что каждый блок алгоритма, показанного на фиг. 1, может быть реализован различными средствами или их комбинациями, например, с помощью аппаратуры, программного обеспечения, микропрограммного обеспечения, одного или более процессоров и/или схем. В соответствии с одним из вариантов осуществления система может содержать несколько устройств таких, например, как сетевой элемент 510 и пользовательское оборудование (UE) или пользовательское устройство 520. Система может содержать несколько UE 520 и несколько сетевых элементов 510, хотя с целью иллюстрации на чертеже показано только одно из этих устройств. Сетевой элемент может представлять собой MTC-IWF или любой другой сетевой элемент, показанный или описанный со ссылкой на Фиг 1, 2 или 3.

[0083] Каждое из этих устройств может содержать по меньшей мере один процессор либо блок или модуль управления, соответственно помеченные как 514 и 524. В каждом устройстве может содержаться по меньшей мере одна память, соответственно помеченная как 515 и 525. В памяти могут храниться компьютерные программные инструкции или компьютерный код, например, для реализации описанных выше вариантов осуществления настоящего изобретения. В состав устройства могут входить один или более приемопередатчиков 516 и 526, и каждое устройство также может быть оснащено антенной, соответственно помеченной как 517 и 527. Хотя на чертеже показана только одна антенна, в каждом устройстве может использоваться множество антенн и множество антенных элементов. Например, могут предлагаться другие конфигурации этих устройств. Например, сетевой элемент 510 и UE 520 может быть дополнительно или исключительно сконфигурирован для проводной связи, и в этом случае антенны 517 и 527 могут иллюстрировать любой вид аппаратуры связи, а не только антенну.

[0084] Приемопередатчики 516 и 526 могут независимо представлять собой передатчик, приемник, совместную схему передатчика и приемника либо блок или устройство, которое может быть сконфигурировано как для передачи, так и для приема. Передатчик и/или приемник (в том что касается компонентов радиосвязи) может быть также реализован в виде дистанционного радиоблока и не располагаться непосредственно в устройстве, а находиться, например, на мачте. Следует также отметить, что в соответствии с "текучей" или гибкой концепцией радиосвязи операции и функции могут гибким образом выполняться в различных объектах таких, как узлы, хосты или серверы. Другими словами, разделение или выполняемые задачи могут изменяться для разных случаев. Один из возможных вариантов использования заключается в доставке сетевым элементом локального контента. Одна или более функций также могут быть реализованы как виртуальное программное приложение, выполняющееся на сервере.

[0085] Пользовательское устройство или оборудование 520 может представлять собой мобильную станцию (MS, Mobile Station), такую как мобильный телефон, смартфон или мультимедийное устройство, компьютер, например планшет, оснащенный средствами беспроводной связи, персональное информационное устройство (PDA, Personal Digital Assistant), оснащенное средствами беспроводной связи, портативный медиаплеер, транспортное средство, цифровая камера, переносная видеокамера, навигационное устройство, оснащенное средствами беспроводной связи, или комбинацию этих устройств. Пользовательское устройство или оборудование 520 может представлять собой датчик или интеллектуальный измерительный прибор, или другое устройство, которое обычно может быть сконфигурировано в одном местоположении. Пользовательское оборудование 520 может представлять собой машину, первоначально сконфигурированную для передачи сообщений МТС.

[0086] В типовом варианте осуществления устройство, такое как узел или пользовательское устройство, может содержать средства для выполнения вариантов раскрытия, описанных выше со ссылкой на фиг. 4.

[0087] Процессоры 514 и 524 могут быть реализованы посредством любого вычислительного устройства или устройства обработки данных, такого как центральный процессор (CPU, Central Processing Unit), цифровой сигнальный процессор (DSP, Digital Signal Processor), специализированная интегральная схема (ASIC, Application-Specific Integrated Circuit), программируемые логические устройства (PLD, Programmable Logic Device), вентильные матрицы (FPGA, Field Programmable Gate Array), цифровые усовершенствованные схемы, или сопоставимого устройства, или комбинации таких устройств. Процессоры могут быть реализованы в виде отдельного контроллера либо множества контроллеров или процессоров. Кроме того, процессоры могут быть реализованы в виде пула процессоров в локальной конфигурации, в облачной конфигурации или в комбинации таких конфигураций.

[0088] Реализация, выполненная с использованием микропрограммного или программного обеспечения, может включать модули или блоки по меньшей мере одного набора микросхем (например, процедуры, функции и т.д.). Память 515 и 525 может независимо представлять собой любое подходящее устройство хранения информации, такое как машиночитаемый носитель информации. С этой целью могут использоваться жесткий диск (HDD, Hard Disk Drive), оперативная память (RAM, Random Access Memory), флэш-память или другая подходящая память. Память может устанавливаться на той же отдельной интегральной схеме, что и процессор, или может располагаться отдельно от него. Кроме того, компьютерные программные инструкции могут храниться в виде любого подходящего для обработки процессором компьютерного программного кода, например, в виде компилируемой или интерпретируемой компьютерной программы, написанной на любом подходящем языке программирования. Память или накопитель данных обычно является внутренним, но также может быть внешним или комбинированным, например, в том случае, если поставщик услуг предоставляет дополнительный объем памяти. Память может быть фиксированной или съемной.

[0089] Память и компьютерные программные инструкции могут быть сконфигурированы таким образом, чтобы при взаимодействии с процессором конкретного устройства аппаратное средство, такое как сетевой элемент 510 и/или UE 520, выполняло процессы, описанные выше (см., например, фиг. 2-4). Таким образом, в определенных вариантах осуществления настоящего изобретения машиночитаемый носитель информации может быть закодирован с помощью компьютерных инструкций или одной или более программ (например, добавленных или обновленных системных программ, апплетов или макросов), при выполнении которых аппаратурой осуществлялся один из процессов, например, один из процессов, описанных выше. Компьютерные программы могут быть закодированы с помощью языка программирования, который может представлять собой язык программирования высокого уровня, такой как объектно-ориентированный язык С, С, С++, С#, Java и. т.д., или язык программирования низкого уровня, такой как машинный язык или ассемблер. В альтернативных вариантах настоящее изобретение может быть реализовано исключительно с помощью аппаратных средств.

[0090] Кроме того, хотя на фиг. 5 показана система, содержащая сетевой элемент 510 и UE 520, варианты осуществления настоящего изобретения могут применяться к другим конфигурациям, а также к конфигурациям, в которых задействованы дополнительные элементы, как обсуждалось выше. Например, может быть задействовано множество пользовательских и множество сетевых элементов или других узлов, выполняющих схожие функции.

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