СИСТЕМА И СПОСОБ ДЛЯ КОРРЕКЦИИ APN В СООБЩЕНИЯХ GTP, АССОЦИИРОВАННЫХ С УСЛУГАМИ ПЕРЕДАЧИ ДАННЫХ GPRS, ПРЕДЛАГАЕМЫМИ МОБИЛЬНЫМ ОПЕРАТОРОМ, ИСПОЛЬЗУЯ СЕТЬ СПОНСОРА Российский патент 2017 года по МПК H04W76/02 

Область техники, к которой относится изобретение

Изобретение относится к способу для коррекции APN (наименование точки доступа) во взаимосвязи роуминга GPRS, где используется сеть оператора-спонсора.

Кроме того, изобретение относится к системе для коррекции APN (наименование точки доступа) в сообщении GTP (протокол туннелирования GPRS) во взаимосвязях роуминга, установленных через двойное/множественное решение роуминга IMSI, где используется сеть оператора-спонсора.

Кроме того, изобретение относится к системе для коррекции APN (наименование точки доступа) в сообщении GTP, для обеспечения услуги GPR для устройств, обслуживаемых MVNO/E (оператор мобильной виртуальной сети/активизатор), используя IMSI оператора-спонсора.

Изобретение также относится к способу для передачи сообщений GTP (протокол туннелирования GPR) между обслуживающим узлом поддержки GPRS (SGSN) и двойной/множественной платформой IMSI во взаимосвязях роуминга для двойного сценария IMSI, в котором используется сеть оператора-спонсора.

Изобретение также относится к способу для передачи сообщений GTP (протокол туннелирования GPRS) между обслуживающим поддерживающим узлом GPRS (SGSN) и GGSN MVNO/E, в котором в MVNO используется IMSI спонсора, но имеет свой собственный уровень базовой сети, включающий в себя GGSN.

Уровень техники

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

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

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

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

Автоматическая модификация APN (наименование точки доступа) представляет собой проблему во взаимосвязях через роуминг с мобильными устройствами, такими, как, например, смартфоны, работающие в сетях GSM (Глобальная система мобильной связи), UMTS (Универсальная мобильная услуга телекоммуникаций) и LTE (долгосрочное развитие). Эти устройства проявляют тенденцию автоматически конфигурировать параметры, относящиеся к GPRS (Общая Услуга пакетной радиопередачи) в соответствии с IMSI (международный идентификатор мобильного абонента), присутствующей на SIM-карте (модуль идентификации абонента), который выбирают во время процесса получения сети. Следовательно, когда IMSI, который выбирают во время обновления информации о местоположении, не является ДОМАШНИМ IMSI, но IMSI, который принадлежит другому оператору-спонсору, конфигурации GPRS, которые активируют в устройстве, будут представлять собой соотношение оператора-спонсора, но НЕ с клиентом/домашней сетью. Таким образом, использование сети спонсора в таком сценарии представляет собой первопричину проблемы. Но использование сети спонсора в сценариях роуминга или MVNO/E в настоящее время составляет основную тенденцию, поскольку обеспечивает более быстрое воплощение, ROI и обладает другими преимуществами, связанными с бизнесом и работой системы. Следовательно, решение для устранения проблемы GPRS является обязательным, поскольку услуги передачи данных GPR не возможны в настоящее время для сценариев роуминга (в случае решений двойного/множественного IMSI) и как для сценариев с роумингом, так и для сценариев без роуминга в случае сетей MVNO/E.

Представленное выше связано с проблемами, например для, по меньшей мере, выполнения следующих двух сценариев воплощения.

- Сценарий 1 представлен в свете решения роуминга двойного/множественного IMSI, где на SIM-карте присутствует один или больше IMSI из других сетей донора/спонсора (другой, чем основной домашний IMSI), которые выбирает мобильная станция для вложенной передачи, используя взаимосвязи роуминга этих доноров/спонсоров. В таком сценарии мобильные устройства, такие как смартфоны, автоматически выбирают APN, принадлежащие сети спонсора. Если HLR (Регистр домашней сети) позволяет загружать APN сети спонсора в SGSN во время процесса обновления местоположения GPRS, тогда сообщения GTP (протокол туннелирования GPRS) направляют в сеть GGSN спонсора вместо домашней сети. Если сеть спонсора не выполнена с возможностью обработки сообщений GTPS сети клиента (клиента MVNO/E или двойного/множественного IMSI), используя свои IMSI, сообщения GTP не будут переданы. Если сеть спонсора выполнена с возможностью обработки сообщений GTP из домашних сетей, используя свои IMSI, тогда все еще остается проблема начисления счетов в режиме реального времени, которая может быть решена только на основе разработки установки (диаметр/GTP7INAP (протокол приложений интеллектуальной сети)/CAMEL (специализированные приложения для расширенной логики мобильной сети), или на частном решении.

- Сценарий 2 предназначен для воплощения MVNO/E (оператор/активизатор виртуальной мобильной сети), где MVNO/E использует IMSI сети спонсора, но тот же MVNO/E имеет свою собственную базовую сеть GPR, которая включает в себя GGSN. Если сообщение GTP GPRS будет запущено из смартфонов, то сообщения GTP будут неправильно направлены в сеть спонсора (который спонсирует IMSI), а не в сеть MVNO.

Как упомянуто выше, проблемы, относящиеся к использованию услуги GPRS устройствами, такими как смартфоны, присутствуют в сетях GSM, UMTS и LTE.

Они вначале будут описаны ниже для сетей GSM, для Сценария 1.

В GSM существует несколько способов установления взаимосвязи роуминга между мобильными операторами. Один из способов состоит в том, чтобы установить обоюдный роуминг между разными подключения для передачи данных между мобильными операторами. В этом случае используется домашний IMSI (Международный идентификатор мобильного абонента) в качестве параметра адресации, для идентификации мобильного пользователя в сети роуминга. Мобильные операторы должны поддерживать логические или физические соединения для передачи сигналов один за другим с сетями - партнерами по роумингу, с тем, чтобы облегчить двусторонний роуминг. В случае, когда существует множество одновременных взаимосвязей роуминга, такие компоновки становятся трудными или плохо управляемыми. Время, требуемое для установления новых взаимосвязей роуминга один за другим, увеличивается экспоненциально таким образом, что это приводит к потере дохода. Другой вариант состоит в том, чтобы подключиться к приложению роуминга и использовать некоторые IMSI другого оператора, уже действующие как IMSI оператора-спонсора, и использовать вложения в уже установленные взаимосвязи роуминга этого операторе спонсора. Такой вид роуминга, основанный на IMSI спонсора, называется мгновенным роумингом, основанным на двойных или на множестве IMSI и является достаточно популярным в настоящее время. Этот вариант также поддерживается в Европейском Союзе.

В настоящее время роуминг с передачей данных GPRS, в сетях GSM/UMTS/LTE, который выполняется с использованием решения двойного/множественного IMSI, имеет проблему, связанную с тем, что когда некоторые устройства вызывают транзакцию, такое как, например, смартфон, вместо обычного телефонной трубки. Большинство смартфонов имеет встроенную постоянную базу данных, содержащую параметры GPRS (такие как APN), отображенные на IMSI. Таким образом, что смартфоны автоматически выбирают установки данных GPRS на основе IMSI, выбранной во время получения сети. Для SIM-карты с двойного/множественного IMSI, когда выбирают спонсора IMSI в местоположении роуминга, выбирают установки GPRS сети спонсора вместо установок клиента двойной IMSI.

Во время обновления местоположения смартфона, если HLR загружает APN сети спонсора в SGSN, в PMN (общедоступная мобильная сеть), которую он посетил через интерфейс GSM MAP (часть мобильного приложения), сообщение управления GTP впоследствии активируют во время установления сеанса (то есть, формируют контекст PDP) по SGSN через интерфейс Gn/Gp. Но сообщения неправильно направляются в GGSN сети спонсора (узел поддержки GPR шлюза) вместо GGSN Домашней сети. GGSN сети спонсора не разработан/не выполнен с возможностью обработки трафика некоторых других сетей, а именно, оператор двойного/множественного IMSI. Следовательно, попытки установления сеанса данных GPRS из этих местоположений являются неудачными. Это приводит к существенному снижению надежности и удобства для пользователя услуги роуминга GPRS. Множество сотовых устройств имеют эту проблему, например, практически все существующие в настоящее время смартфоны/планшетные компьютеры.

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

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

Проблему ухудшает то, что изготовители телефонных трубок неохотно изменяют или не желают изменять поведение телефонной трубки, поскольку это может привести к серьезным проблемам для клиентов, для обычных решений роуминга с передачей данных (не через множественный/двойной IMSI) и/или использующих GPRS в домашней сети. Установки GPRS телефонной трубки изменяются в таком случае, и, следовательно, их GPRS будут не пригодны для использования, пока не будут введены установки вручную. Однако, хотя множество людей используют смартфоны и аналогичные устройства, только небольшое меньшинство фактически имеет технические знания о том, как выполнить такие действия.

Поставщики OS (Операционной системы), Android/Symbian/Windows/Mac не могут легко решить эту проблему, используя программное исправление или новый выпуск в связи с проблемами воплощения, неизвестными побочными эффектами с другими сценариями и также с проблемами взаимодействия (телефонных трубок с более старыми версиями). Они также не желают изменять это поведение, поскольку это может привести к серьезным проблемам для клиентов, использующих обычное решение роуминга с передачей данных (через множественные/двойные IMSI) и используя GPRS в домашней сети. Следует отметить, что старые версии смартфонов (до 2008 г.) не имели базы данных для отображения параметров GRPS для APN. Изготовители телефонных трубок захотели сделать телефонные трубки более интеллектуальными и менее зависящими от выполняемых вручную процессов конфигурации или с использованием передаваемых по радиоканалу SMS, активируемых операторами. Но они, возможно, не предвидели побочного эффекта (автоматическая модификация APN устройством) с учетом предоставления услуги GPRS через сеть спонсора.

Существуют несколько решений, но все они имеют собственные проблемы:

- GGSN сети спонсора может быть выполнен с возможностью обработки трафика GPR клиента с двойным/множественным IMSI: проблема, связанная с этим решением состоит в том, что невозможно поддерживать начисление счетов с предварительной оплатой (кроме CAMEL (Специализированные приложения для расширенной логики мобильной сети)), таким образом, что это решение невозможно оплатить. Существуют серьезные воздействия, связанные с начислением счетов. GGSN сеть спонсора должна быть перестроена для обслуживания трафика GRRS других сетей. Также возникают проблемы, связанные с безопасностью и мошенничеством.

- Разработка сценария: некоторые сценарии Android/Symbian могут быть разработаны для того, чтобы всегда принудительно устанавливать домашние установки GPRS. Однако, это не работает для каждой телефонной трубки Android/Symbian. Это также не обеспечивает решение для IPhone, телефонов системы Windows и смартфонов, которые не имеют OS (например, Samsung Star).

- Апплет SIM в SIM-карте может принудительно устанавливать домашний APN во время включения питания. Время, необходимое для получения сети увеличивается многократно, из-за плохого QOS (качество обслуживания), что также приводит к жалобам клиентов. Некоторые клиенты используют SIM-карты с множеством IMSI, и проблема многократно увеличивается для такой ситуации. При этом отсутствуют какие-либо решения для защиты от случайных ошибок, поскольку не существует агностики для поведения телефонной трубки, и она не работает для всех телефонных трубок.

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

Для услуги GPRS, аналогичные проблемы возникают для MVNO/MVNE (Оператор мобильной виртуальной сети/активизатор мобильной электронной сети):

Многие MVNO/MVNE не имеют свой собственный диапазон IMSI. Но они имеют диапазон IMSI, предоставляемый оператором спонсора. Установка для такого MVNO может быть следующей.

- MVNO имеет IMSI спонсора на SIM-карте и определил свой профиль, существующий в HLR

- MVNO имеет свою собственную установку в базовой сети, а именно, GGSN.

- MVNO имеет свой собственный APN, а не APN оператора-спонсора для роуминга данных

- MVNO, однако, определил APN оператора-спонсора или универсальный шаблон в профиле абонента в HLR таким образом, что VLR может разрешить GTP-C формировать контекст PDP, который вызывает APN оператора-спонсора (применимый для случая смартфона).

В этом сценарии, когда абонент инициирует сеанс данных из дома или из местоположения в роуминге, сообщение GTP будет неправильно направлено в GGSN оператора-спонсора. Это связан с тем фактом, что APN, выбранный смартфоном, будет представлять собой APN сети спонсора, а не APN домашней сети.

Если GGSN сети спонсора не имеет возможности обрабатывать трафик из сети MVNO/MVNE, тогда трафик GTP будет неудачным. Следовательно, услуга GPR не будет возможна из таких устройств, как смартфоны.

Даже если GGSN сети спонсора будет выполнен с возможностью обрабатывать трафик, все еще будет довольно трудно производить начисление счетов в режиме реального времени для предварительной оплаты. Чтобы сделать ее возможной, оператор спонсора должен установить интерфейс начисления счетов в режиме реального времени с SCP домашней сети. Это также подразумевает то, что HPMN (MVNE/O) также должен представить в совместное использование чувствительную информацию, относящуюся к начислению счетов, со спонсором, что может оказаться затруднительным с точки зрения бизнеса.

Следовательно, все еще отсутствует решение для защиты от ошибочных действий, которое могло бы охранять эти сложные проблемы и которое сделало бы простым развитие услуги GPRS, как для спонсора, так и для MVNO/E.

Оба сценария имеют типичную проблему, состоящую в том, что сообщения GTP невозможно передать, поскольку их неправильно направляют в GGSN оператора-спонсора.

Раскрытие изобретения

Цель изобретения состоит в том, чтобы предоставить для сценария 1 решение для сети клиента/домашней сети без каких-либо требований на конце оператора-клиента воплотить какое-либо специальное программное обеспечение или аппаратные средства для обеспечения GPRS для смартфонов и без необходимости учета оператором какой-либо специальной установки для начисления счетов в режиме реального времени.

Для сценария 2 цель изобретения состоит в том, что предусмотреть решение для MVNO, для приема сообщений GPRS всегда в направлении их собственной базовой сети, даже если сообщение будет направлено такими устройствами, как смартфоны. После того, как сообщение будет направлено через решение фильтра GTP в направлении GGSN MVNO/E, GGSN будет агностиком того факта, что GTP поступает от смартфонов. Нормализация параметра GTP будет выполнена приложением фильтра GTP таким образом, что сообщение GTP, поступающее из устройств, таких как смартфоны, выглядит аналогичным сообщению GTP, поступающему из обычных устройств (которые не конфигурируют автоматически APN).

С этой целью в способе для коррекции APN, во взаимосвязи роуминга, где используется сеть оператора-спонсора, предусмотрен фильтр GTP, в котором, когда в фильтр GTP поступает сообщение сформировать контекст PDP из узла поддержки обслуживания GPRS, проверку выполняют с помощью фильтра GTP для данных IMSI и APN на уровне GTP, в котором, в зависимости от контекста данных IMSI и APN на уровне GTP, фильтр GTP модифицирует параметры GTP в плоскости управления GTP для направления трафика плоскости управления в правильное место назначения (двойная/множественная платформа IMSI или GGSN в MVNO/E, в соответствии со сценарием воплощения) после коррекции APN, в то время как трафик уровня данных устанавливается непосредственно между обслуживающим узлом поддержки GPRS и узлом поддержки GPRS шлюза (для сценария MVNO/E или платформы двойного/множественного IMSI).

Манипуляции в сообщениях GTP, выполняемые с помощью фильтра GTP, примеры которых будут представлены ниже в блок-схемах последовательности вызова, обеспечивают такие эффекты.

Это позволяет исправлять маршрутизацию для решения описанной выше проблемы.

В первом варианте осуществления, в котором IMSI во входящем сообщении контекста PDP принадлежит абоненту или сети спонсора, и APN принадлежит спонсору, фильтр GTP не выполняет модификацию и не выполняет APN адреса SGSN на уровне GTP, заполняет IP места назначения, равным IP GGSN сети спонсора на уровне IP, и виртуализирует номер последовательности для поддержания состояния и возвращается для формирования отклика контекста PDP в направлении SGSN, который вызвал формирование сообщения контекста PDP.

Во втором варианте осуществления, в котором IMSI во входящем сообщении контекста PDP принадлежит абоненту клиента двойного/множественного IMSI или сети MVNO, и APN принадлежит спонсору, фильтр GTP выполняет следующее:

- не выполняет никаких модификаций для адреса SGSN на уровне GTP,

- заполняет IP места назначения, равным IP платформы двойного/множественного IMSI или IP GGSN для MVNO/E (в соответствии со сценарием воплощения) на уровне IP,

- переводит APN от спонсора в домашний APN,

- виртуализирует номер последовательности, для поддержания состояния и возврата сформированного ответа контекста PDP в направлении SGSN, который вызвал формирование сообщения вызова контекста PDP.

В третьем варианте осуществления, в котором IMSI в поступающем сообщении контекста PDP принадлежит абоненту сети спонсора, и APN не принадлежит спонсору, но корпоративной APN, фильтр GTP направляет сообщения в направлении GGSN сети спонсора без модификаций в IP или уровне GTP.

В четвертом варианте осуществления IMSI в поступающих сообщениях контекста PDP принадлежит абоненту клиента двойного/множественного IMSI или сетям MVNO, и APN не принадлежит спонсору, но корпоративной APN, фильтр GTP направляет сообщения в направлении GGSN клиента двойного/множественного IMSI или в сеть MVNO без модификаций IP или уровня GTP.

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

Система для коррекции APN во взаимосвязях роуминга, где используется сеть оператора-спонсора, содержит фильтр GTP, выполненный с возможностью выполнения описанных выше этапов в способе для коррекции APN.

В способе для передачи сообщений GTP (протокол туннелирования GPRS) между обслуживающим узлом поддержки GPRS (SGSN) и платформой двойного/множественного IMSI во взаимосвязи роуминга для сценария двойного/множественного IMSI, в котором используется сеть оператора-спонсора, предусмотрен фильтр GTP, выполненный с возможностью активации логики потока вызова для маршрутизации трафика GTP между SGSN и платформой двойного IMSI для направления трафика уровня управления, имеющего отношение к GPR, GTP через фильтр GTP, в то время как трафик уровня данных направляют непосредственно между обслуживающим узлом поддержки GPRS и платформой двойного/множественного IMSI, без прохода через фильтр GTP.

Манипуляции с фильтром в сообщении уровня управления GTP (контекст формирования PDP) включают этот эффект.

В способе для передачи сообщения GTP (протокол туннелирования GPR) между обслуживающим узлом поддержки GPRS (SGSN) и GGSN MVNO/E, в котором MVNO использует IMSI спонсора, но имеет свой собственный уровень базовой сети, включающий в себя GGSN, предусмотрен фильтр GTP, который расположен для активации вызова из логики, для направления трафика GTP между SGSN и GGSN MVNO/E, для направления только GTP-контекста PDP формирования управления через фильтр GTP, в то время как другие сообщения управления GTP, а также трафик уровня данных, направляются непосредственно между обслуживающим узлом поддержки GPR и GGSN MVNO/E, без пропуска через фильтр GTP.

Манипуляция, использующая фильтр в сообщении на уровне управления GTP (Контекст формирования PDP) обеспечивает эти эффекты.

Способ передачи, предпочтительно, содержит следующие этапы: когда инициирован запрос DNS из обслуживающего узла поддержки GPRS в сеть оператора-спонсора, DNS возвращает адрес IP фильтра IP GTP и, когда поступает следующий контекст формирования PDP из обслуживающего узла поддержки GPRS, фильтр GTP выполняет проверку с помощью фильтра GTP для IMSI и данных APN на уровне GTP, в котором

в зависимости от контекста IMSI и данных APN на уровне GTP, фильтр GTP модифицирует IP-адрес (источник и место назначения) в плоскости IP, но не модифицирует адрес SGSN в сообщении вызова контекста PDP формирования GTP-управления.

Аналогично, в ответном сообщении контекста PDP формирования GTP-управления, поступающего из платформы двойного/множественного IMSI или GGSN для MVNO/E (как для сценария воплощения), фильтр GTP не меняет адрес GGSN IP уровня GTP.

Эти этапы способа просто обеспечивают то, что

- трафик контекста PDP формирования управления GTP направляется через фильтр GTP,

- сообщения плоскости управления GTP, кроме контекста формирования PDP и трафика плоскости данных устанавливают непосредственно между SGSN (обслуживающим узлом поддержки GPRS), и GGSN (узел поддержки GPRS шлюза) MVNO/E или платформы двойного/множественного IMSI, в соответствии с применимым вариантом.

Обход фильтра GTP для сообщений плоскости GTP-управления, кроме контекста формирования PDP и трафика плоскости данных подразумевает, что оператор обеспечивает то, что оператор может предложить то же качество обслуживания и не будет формировать какую-либо дополнительную латентность.

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

На первом этапе способа для логической схемы маршрутизации, оператор спонсора в DNS (Система наименования домена) реконфигурирует IP-адрес так, чтобы он был разрешен относительно его собственных (оператора-спонсора), APN для IP-адресов фильтра GTP. Следовательно, если существует поиск сервера по наименованию для запроса DNS в направлении DNS оператора-спонсора с APN оператора-спонсора, после которого следует NNC/MCC (код мобильной сети/код страны мобильной связи) оператора-спонсора, он предоставляет IP-адрес фильтра GTP. IP фильтра GTP предпочтительно выбирают из диапазона IP, зарезервированных оператором, для представления в GSN (узел поддержки GPRS) IP магистральной линии передачи данных PMN (общедоступная мобильная сеть). Этот IP должен происходить из того же набора IP магистральной сети GSN PMN, включенного в IR21 оператора-спонсора.

Вход в корпоративные APN (например, Blackberry), остается неизменным в DNS. Это разрешает GGSN оператора-спонсора (узел поддержки шлюза GPR) в отношении поиска DNS, инициируемого SGSN.

Затем, когда SGSN (обслуживающий узел поддержки GPR) партнера по роумингу вызывает формирование контекста PDP, его посылают в направлении фильтра GTP, который позволяет фильтру GTP анализировать разные параметры, в частности, данные IMSI и APN, для определения следует ли направить сообщение далее в платформу D-IMSI/GGSN для MVNO/E после активации коррекции APN или в направлении GGSN оператора-спонсора, без модификации какого-либо параметра на уровне GTP.

Во время передачи сообщения в направлении GGSN оператора-спонсора или в направлении платформы D-IMSI, фильтр GTP заполняет свой собственный адрес IP, как исходный IP-адрес и, следовательно, фактически вынуждает обратное сообщение проходить через фильтр GTP.

Поэтому, обратное сообщение из GGSN оператора-спонсора или платформу D-IMSI или GGSN MVNO/E посылают обратно в фильтр GTP, и это обеспечивает для фильтра GTP возможность манипуляций с IP-адресами на уровне IP перед направлением формирования ответа контекста PDP обратно в SGSN. Когда GTP представляет собой UDP, фильтр выполняет перестановку/реверсирование значений источника и назначения IP в ответном сообщении в направлении SGSN по сравнению с сообщением вызова. Это обеспечивает то, что ответное сообщение не будет отклонено SGSN, из-за несоответствия IP-адресов на уровне IP между вызывающим и ответным сообщениями.

В случае когда последовательность операции вызова для GTP направляется к GGSN оператора-спонсора, фильтр GTP выполняет запрос DNS, для поиска IP-адреса GGSN оператора-спонсора (множества IP при совместном распределении нагрузки).

В случае потока вызова маршрутизации GTP в направлении платформы двойного/множественного IMSI или GGSN MVNO/E, запрос DNS не инициируют с помощью фильтра GTP. Вместо этого, эти адреса отображают на платформу и направляют в место назначения после применения логики коррекции APN.

Кроме того, поскольку в качестве механизма безопасности и, если поддерживается сетью спонсора, здесь может присутствовать механизм IP SLA (соглашение об уровне обслуживания) между DNS и фильтром GTP. DNS переводит сигнал проверки связи в специфичный порт фильтра GTP для воплощения механизма IP SLA. Сигнал проверки связи может представлять собой сигнал уровня IP или сигнал проверки связи уровня приложения, такой как запрос эхо-сигнала GTP. Путем передачи сигнала проверки связи в фильтр IP GTP и в конкретный порт фильтра GTP, он проверяет исправность состояния. Если платформа фильтра GTP не исправна, или если порт LAN является не доступным, результат передачи сигнала проверки связи будет отрицательным, DNS динамически заменяет IP-адрес (в отношении APN оператора-спонсора) с IP-адреса фильтра GTP на его собственный IP-адрес GGSN. Это обеспечивает то, что, в конечном итоге решения всех проблем работы с фильтром GTP, весь трафик будет пропущен в обход фильтра GTP, и при этом не будет, оказано влияние на трафик GPRS сети спонсора.

После активации контекста PDP выполняют непосредственный обмен последующими сообщениями управления GTP и трафиком GTP-U (плоскость данных) между обслуживающим узлом поддержки GPR и GGSN для MVNO/E или платформы двойного/множественного IMSI или GGSN СЕТИ СПОНСОРА. Это связано с тем фактом, что фильтр GTP не изменяется после того, как IP-адрес GSN обращается к уровню GTP и реальный SGSN и IP-адреса платформы GGSN/D-IMSI сохраняются.

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

Изобретение обеспечивает еще одно из преимуществ:

Изобретение позволяет выполнять роуминг данных, без какого-либо изменения или зависимости от специализации телефонных трубок или мобильных сетей. Клиент двойного/IMSI не должен выполнять какие-либо существенные изменения сети, для воплощения решения для фильтра GTP, и, следовательно, не оказывается какое-либо влияние на CAPEX (капитальные затраты). Изобретение работает как для абонентов с предварительной оплатой (не Camel), так и для абонентов с последующей оплатой.

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

Способ и система, в соответствии с изобретением манипулируют специфичным сообщением трафика управления GTP для активации контекста пакетных данных. Оно не связывается непосредственно само с потоком других сообщений управления GTP и сообщений плоскости пользователя GTP (поток данных). Следовательно, способ и система, в соответствии с изобретением, не влияют каким-либо образом на QOS.

В предпочтительных вариантах осуществления фильтр GTP остается за пределами ветви трафика данных.

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

Это решение основано на манипуляции существующими параметрами GTP. Способ и система изобретения не обязательно требуют изменения ограничений стандартов 3 GPP для GPRS для разработки/предложения любого нового параметра GTP, для обработки логической услуги. Более точно, параметры GPRS являются таким же, но их значения изменяются интеллектуальным образом для того, чтобы способствовать логике обслуживания. Решение может быть воплощено с помощью GRX или провайдера двойного/множественного IMSI или даже в пределах базовой сети мобильного оператора.

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

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

На фиг. 1 представлен алгоритм, выполняемый в фильтре GTP, и способ, в соответствии с изобретением.

На фиг. 2 представлен поток данных для первого варианта осуществления способа и системы, в соответствии с изобретением.

На фиг. 3 представлен поток данных для второго варианта осуществления способа и системы по изобретению.

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

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

Осуществление изобретения

На фиг. 1 представлен пример алгоритма, в соответствии с которым работает фильтр GTP. Фильтр GTP схематично обозначен прямоугольником из пунктирных линий.

На этапе 1 овал обозначает, что оператор спонсора реконфигурировал IP-адрес в DNS для его собственного APN (оператора-спонсора), в отношении IP-адреса фильтра GTP. Следовательно, если присутствует nslookup в DNS оператора-спонсора в MNC/MCC оператора-спонсора, то он разрешает IP-адрес фильтра GTP. IP фильтр GTP будет назначен из набора магистральной линии передачи GSN IP PLMN, уже включенного в IR21 оператора-спонсора. Корпоративный APN и Blackberry, однако, все еще будут направляться в GGSN оператора-спонсора.

Контекст PDP формирования GTP-C затем поступает в фильтр GTP. Фильтр GTP выполняет проверку по 2 параметрам на уровне GTP сообщения. Они представляют собой следующие:

- IMSI & APN

На фиг. 1 обозначены пункты A и B.

В зависимости от того, какой пункт будет найден, выполняется набор действий по маршрутизации на этапах 2 и 4.

Примеры таких действий представляют собой:

Действия 1 маршрутизации:

- Изменение APN от спонсора на домашнего в соответствии с таблицей отображения APN

- Установить IP источника для IP-адреса GTP в сообщении, Сформировать контекст PDP, который передают в двойной/множественный EMSI/GGSN для MVNO

- Отсутствие изменения в IP-адресах на уровне GTP/TEID в переданном сообщении Сформировать контекст PDP.

- установить IP места назначения, как платформу двойной/множественной IMSI/GGSN в MVNO, в переданном сообщении Сформировать контекст PDP.

- Сгенерировать номер последовательности и поддерживать этот номер последовательности для корреляции транзакции в последующем (во время обработки результата возвратного сообщения Сформировать контекст PDP из двойного/множественного IMSI или GGSN для MVNO/E).

- Когда возвратное сообщение принимают, скоррелировать транзакцию путем корреляции номера последовательности (входящего и исходящего сообщения). Затем фильтр GTP находит SGSN, куда должен быть направлен результат.

- Корреляция транзакции активируется путем проверки отображения номера последовательности, первоначально принятого из SGSN при вызове Сформировать контекст PDP с тем, что было сгенерировано Фильтром GTP для направления Сформировать контекст PDP в двойной/множественный IMSI/GGSN в MVNO

Действие 2 маршрутизации:

- Содержать APN

- Установить IP источника для IP-адреса GTP в сообщении Сформировать контекст PDP, переданном в GGSN оператора-спонсора

- Найти IP GGSN оператора-спонсора путем вызова NSLOOKUP в направлении DNS оператора-спонсора.

- Последовательно передавать Сформировать контекст PDP в GGSN оператора-спонсора

- Не выполнять никакие изменения в IP-адресах на уровне GTP/TEID в переданном сообщении

- Установить IP места назначения на платформу двойного/множественного IMSI/GGSN MVNO

- Сгенерировать номер последовательности и поддерживать этот номер последовательности, для корреляции транзакции в последующем (во время обработки результата возврата).

- Отсутствуют какие-либо изменения в IP на уровне GTP в сообщении вызова

- Когда принимают возвратное сообщение, коррелировать транзакцию путем корреляции номера последовательности (входящего и исходящего сообщения). Затем фильтр GTP находит SGSN, куда должен быть направлен результат

- Корреляция транзакции активируется путем проверки отображения номера последовательности, первоначально принятого из SGSN при вызове Сформировать контекст PDP с тем, что было сгенерировано фильтром GTP для направления Сформировать контекст PDP в GGSN спонсора.

Этапы 3 и 5 на фиг. 1 обозначают, что сообщение перенаправляется в один из двойного или множественного IMSI (этап 3) или GGSN MVNO (этап 5). Фильтр GTP схематично обозначен прямоугольником с пунктирными линиями. Платформа двойного/множественного IMSI может быть платформой двойного, а также множественного IMSI. Использование слова "двойной/множественный" не является ограничением для любой из двух возможностей, для платформы IMSI множественный может представлять собой любое число, большее двух.

Фильтр GTP, предпочтительно, имеет таблицу отображения APN, которая содержит во взаимно однозначном отношении данные отображения APN между APN во входящем сообщении Сформировать контекст PDP (принадлежит оператору спонсора), и APN в исходящем сообщении Сформировать контекст PDP (принадлежит оператору двойного/множественного IMSI/MVNO).

В качестве примера:

Предположим, что оператор APN спонсора (выбранный смартфоном, когда выбирают IMSI спонсора для фиксации сети), => wap.sponsoroperator.net

Предположим для оператора двойного/множественного IMSI/MVNO APN => wap.homenetwork.net Таким образом, когда фильтр GTP принимает сообщение Сформировать контекст PDP из SGSN с APN = wap.sponsoroperator.net и находит, что спонсор IMSI принадлежит оператору двойного/множественного IMSI/MVNO, тогда он будет переводить APN в wap.homenetwork.net, в сообщении, которое фильтр GTP передает в платформу двойного/множественного IMSI или GGSN MVNO (что применимо).

Дополнительную обработку, в соответствии с логикой услуги, выполняют, например, следующим образом:

Любые сообщения запроса эхо-сигнала, поступающие из фильтра GTP, отправляют обратно с IP-адресом фильтра GTP (в качестве источника). Сообщения запроса эхо-сигнала, поступающие из SGSN, не будут перенаправлены GSN или двойной/множественный IMSI. При этом должен выполняться непосредственный обмен сообщениями запроса эхо-сигнала между SGSN и GGSN, или платформой двойного/множественного IMSI.

При перенаправлении сообщения в направлении GGSN оператора-спонсора или в направлении платформы двойного/множественного IMSI/GGSN MVNO/E, фильтр GTP заполняет свой собственный IP-адрес, как IP-адрес места происхождения, и, следовательно, фактически, принудительно пропускает обратное сообщение через фильтр GTP.

Обратное сообщение от GGSN оператора-спонсора или платформы двойного/множественного IMSI должно возвращаться обратно в фильтр GTP, поскольку фильтр GTP должен манипулировать IP-адресами (как при потоке вызова) на уровне IP перед перенаправлением ответа сформировать ответ контекста PDP обратно в SGSN.

Поскольку GTP представляет собой UDP, IP источника и места назначения в ответном сообщении, направляемом в SGSN, необходимо переключать по значениям, как в сообщении вызова. Следовательно, фильтр GTP должен активировать манипуляцию в ответном сообщении Сформировать контекст PDP, который фильтр GTP перенаправляет к месту назначения, путем заполнения IP фильтра GTP в поле IP источника.

На фиг. 2-4 иллюстрируются различные потоки обработки вызова для направления по маршруту сообщения.

На фиг. 2, 3 и 4 представлена информация в различных выносках, содержащих текст.

Для упрощения чтения различная информация и потоки вызова обозначены в виде выносок с текстом, с кратким описанием информации "Фильтр 1 GTP", "Информация Сформировать контекст PDP 1" и т.д.

Примеры такой информации и потоков обработки вызова представлены ниже.

На фиг. 2 иллюстрируется направление сообщения в GGSN оператора-спонсора.

Способ начинается с запроса DNS, передаваемого DNS оператора-спонсора (этап 21).

Оператор спонсора реконфигурирует в DNS IP-адрес для своих собственных APN (оператор спонсора) в IP-адрес фильтра GTP. В возвратном сообщении (этап 22) предоставляется эта информация. Сообщение Сформировать контекст PDP из GTP-C затем поступает в фильтр GTP (этап 23).

Пример такого контекста может представлять собой:

"Сформировать контекст 1 PDP" на фигуре, показано краткое обозначение потока вызова, например, для следующего:

Сформировать контекст PDP

IP источника IP=SGSN

IP места назначения = Фильтр GTP (общедоступный)

Заголовок GTP

IP SGSN для C = real SGSN для U = real

TEID для GGSN (С) = сгенерирован SGSN

TEID для GGSN (С) = сгенерирован SGSN

IMSI = Оператор-спонсор

APN = wap.SponsorOperator.net

номер последовательности =nl.

Следующий этап схематично обозначен на фигуре, как "Информация фильтра 1": фильтр GTP проверяет IMSI и данные APN. В этом случае фильтр GTP анализирует IMSI, для определения, что он принадлежит оператору спонсора, поскольку часть MSIN в IMSI не содержит идентификатор сети (обычно 2-6 цифр) сети двойного/множественного IMSI или MVNO/E. Следовательно, фильтр GTP направляет сообщение в GGSN сети спонсора без каких-либо изменений, и оно поступает в пункт A, в представленной выше таблице (таблица 1).

Перед направлением сообщения в GGSN оператора-спонсора, фильтр GTP должен определить GGSN оператора-спонсора. Следовательно, фильтр GTP передает второй DNS запроса в DNS оператора-спонсора (этап 24). DNS оператора-спонсора возвращает в фильтр GTP IP-адрес GGSN оператора-спонсора (этап 25).

Затем фильтр GTP направляет сообщение Сформировать контекст PDP в GGSN@ сеть оператора-спонсора (этап 26)

"Сформировать контекст 2 PDP":

Сформировать контекст PDP

IP источника = фильтр GTP

IP места назначения = оператор спонсора GGSN

Заголовок GTP

IP SGSN для C = real

SGSN для U = real

TEID для GGSN (С) = сгенерирован SGSN

TEID для GGSN (U) = сгенерирован SGSN

IMSI = оператор-спонсор

APN = wap.SponsorOperator.net

номер последовательности = kl.

Фильтр GTP принимает отклик контекста PDP из GGSN сети оператора-спонсора (этап 27):

"отклик 1 Сформировать контекст PDP":

Отклик Сформировать контекст PDP

Оператор спонсора источника IP=GGSN

IP места назначения = фильтр GTP

Заголовок GTP

IP GGSN для C = real IP

GGSN для IP U = real

TEID для SGSN (С) = сгенерирован GGSN

TEID для SGSN (U) = сгенерирован GGSN

номер последовательности = kl.

Фильтр GTP (этап схематично обозначен на фигуре, как "информация фильтра 2 GTP") модифицирует IP источника и IP места назначения, для сохранения четности уровня IP с сообщением вызова. Фильтр GTP использует номер последовательности для корреляции транзакции и находит SGSN, который вызывает сообщение Сформировать контекст PDP и передает отклик Сформировать контекст PDP в направлении SGSN (этап 28)

"отклик 2 Сформировать контекст PDP":

отклик Сформировать контекст PDP

IP источника = Фильтр GTP

IP места назначения = SGSN VPMN

Заголовок GTP

IP GGSN для C = real IP

GGSN для U = real IP

TEID для SGSN (С) = сгенерирован GGSN

TEID для SGSN (U) = сгенерирован GGSN

номер последовательности =nl.

Последующие сообщения GTP - С & U (этапы 29 и 30) не проходят через фильтр GTP (информация фильтра 3), но обмен ими выполняют непосредственно между SSGN для VPLMN MNO и GGSN сети оператора-спонсора.

"GTP U/C пакет 1"

GTP U/C пакет 1

IP источника = SGSN

IP места назначения = GGSN

заголовок GTP

TEID = real

"GTP U/C пакет 2"

пакета GTP U/C

IP источника = GGSN

IP места назначения SGSN

заголовок GTP

TEID = real

На фиг. 3 иллюстрируются потоки вызова для направления по маршруту сообщения в направлении GGSN MVNO.

Первые два этапа (этапы 31-32) представляют собой обмен картой местоположения GPR между SGSN в VPLMN MNO и GGSN MVNO. Для HLR MVNO требуется предоставить либо (*) универсальный символ или APN оператора-спонсора в профиле абонента. Во время процесса обновления местоположения GPRS HLR загружает (*) универсальный символ или APN оператора-спонсора в профиль VLR пользователя.

Этапы 33 и 34 соответствуют этапам 21 и 22 на фиг. 2.

Сформировать контекст 1 PDP

IP источника = SGSN VPMN

IP места назначения = Фильтр GTP (общедоступный)

Заголовок GTP

IP SGSN для C = real

IP SGSN для U = Real

TEID для GGSN (С) = сгенерирован SGSN

TEID для GGSN (U) = сгенерирован d SGSN

IMSI = Оператор-спонсор

APN = wap.Sponsor operator.net

номер последовательности =nl

Фильтр GTP перенаправляет вызов Сформировать контекст PDP в GGSN MVNO/E после выполнения коррекции APN для домашней APN в исходящем сообщении. Он также изменяет номер последовательности и поддерживает состояние (Информация фильтра 4 GTP).

Сформировать контекст 3 PDP

IP источника = фильтр GTP

IP назначения = GGSN MVNO

заголовок GTP

IP SGSN для C = real

SGSN IP для U = Real

TEID для GGSN (С) = сгенерирован SGSN

TEID для GGSN (U) = сгенерирован SGSN

IMSI = Оператор-спонсор

APN = wap.HomeNetwork.net

номер последовательности = kl.

Этапы 37 и 38 соответствуют этапам 27 и 28 на фиг. 2, за исключением того, что GGSN MVNO передает ответ Сформировать контекст PDP в фильтр GTP:

"Сформировать ответ 3 контекста PDP":

Сформировать ответ контекста PDP

IP источника = GGSN для MVNO

IP назначения = фильтра GTP

Заголовок GTP

IP GGSN для С = концентратор

GGSN для U = концентратор

TEID для SGSN (С) = концентратор

TEID для SGSN (U) = концентратор

номер последовательности = kl.

"сформировать ответ 4 контекста PDP":

Сформировать ответ контекста PDP

источник IP = фильтр GTP

назначения IP = SGSN VPMN

заголовок GTP

IP GGSN для С = концентратор

GGSN для U = концентратор

TEID для SGSN (С) = концентратор

TEID для SGSN (U) = концентратор

номер последовательности = nl.

Этапы 39 и 40 соответствуют этапам 29 и 30, за исключением того факта, что с правой стороны расположен GGSN MVNO на фиг. 3, где был расположен GGSN сети оператора-спонсора на фиг. 2.

На фиг. 4 иллюстрируется поток обработки вызова для маршрутизации сообщения в направлении двойного/множественного IMSI

С правой стороны представлен блок между пунктирными линиями. Этот блок в потоке обработки вызова иллюстрирует обычное поведение платформы двойного/множественного IMSI и был предусмотрен для полноты обработки вызова. Также этапы 41-44 представляют собой часть обычного потока обработки вызова для платформы двойного/множественного IMSI.

Этапы 45, 46 и 47 соответствуют этапам 21, 22 и 23 по фиг. 2. Этапы 52 соответствуют этапу 28 на фиг. 2; этапы 48, 51, 53 и 54 на фиг. 4 соответствуют этапам 26, 27, 29 и 30 на фиг. 2, за исключением того факта, что с правой стороны на фиг. 4 расположена платформа двойного/множественного IMSI, где на фиг. 2 была расположена GGSN сети оператора-спонсора.

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

"Сформировать контекст 4 PDP":

IP источника = GTP фильтр ΙΡ1/IΡ2

IP места назначения = ПЛАТФОРМА двойного/множественного IMSI

Заголовок GTP

IP SGSN для C = real

IP SGSN для U = Real

TEID для GGSN (С) = сгенерирован SGSN

TEID для GGSN (U) = сгенерирован SGSN

IMSI = Оператор-спонсор

APN = wap.Home Network.net

"Сформировать контекст 5 PDP":

IP источника = Платформа двойного/множественного IMSI

IP назначения = Домашний GGSN

Заголовок GTP

IP SGSN для С = концентратор

SGSN для U = концентратор

ТЕГО для GGSN (С) = концентратор

TEID для GGSN (U) = концентратор

IMSI = Домашний IMSI

APN = wap.Home Network.net

"Сформировать ответ 5 контекста PDP":

Сформировать ответ контекста

IP источника = Домашний GGSN

IP Назначения = Платформа двойного/множественного IMSI

Заголовок GTP

IP GGSN для С = IP GGSN

GGSN для U = IP GGSN

TEID для SGSN (С) = сгенерирован GGSN

TEID для SGSN (U) = сгенерирован GGSN

"Сформировать ответ 6 контекста PDP":

Сформировать ответ контекста PDP

IP источника = Платформа двойного/множественного IMSI

IP Назначения = Фильтр GTP

Заголовок GTP

IP GGSN для С = концентратор

GGSN для U = концентратор

TEID для SGSN (С) = концентратор

TEID для SGSN (U) = концентратор

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

Во всех различных примерах проблема автоматической APN, из-за автоматической конфигурации APN на основе IMSI с последующей перемаршрутизацией сообщений GTP в соответствующее место назначения была решена надежным и простым способом.

Вкратце изобретение может быть описано следующим образом.

В способе и системе для модификации/коррекция APN (наименование точки доступа) в сценарии с роумингом на основе услуги двойного/множественного IMSI, где используется сеть оператора-спонсора, и способ, и система для перенаправления сообщений GTP в соответствующее место назначения, то есть домашнюю сеть.

В способе и системе для модификации/коррекции в APN (наименование точки доступа) в сценариях с роумингом или без роуминга услуга GPRS, предлагаемая MVNO/E, где используется сеть оператора-спонсора и способ, и система для перемаршрутизации сообщений GTP в соответствующее место назначения, то есть, в домашнюю сеть.

Фильтр GTP проверяет данные IMSI и данные APN на уровне GTP и, в зависимости от IMSI и данных APN, манипулирует параметрами GTP в плоскости управления GTP, для обеспечения маршрутизации сообщения, для коррекции APN в соответствующее место назначения. Такое решение позволяет выполнять роуминг данных из таких устройств, как смартфоны, в конкретных сценариях, таких как роуминг с двойным/множественным IMSI, или роуминг данных GPRS, предлагаемых MVNO/E, используя IMSI сети спонсора, но воплотило свою собственную базовую сеть GPR.

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

Конфигурации, предпочтительные в сети двойного/множественного IMSI/MVNO-E

1. Предоставление в HLR: клиент предоставляет универсальный символ (*) или APN сети спонсора в своих HLR, в профиле абонента.

2. Клиент двойного/множественного IMSI/MVNO/Е принимает домашний APN в своей GGSN, таким образом, что представленная выше APN не обязательно должна быть предоставлена в GGSN клиента двойного/множественного IMSI.

3. Отображение (конфигурация) между APN сети спонсора и APN клиента двойного/множественного IMSI удостоверяется и одобряется клиентом двойного/множественного IMSI.

4. Имя пользователя/пароль: трафик GTP-U все еще будет иметь имя пользователя СЕТИ СПОНСОРА и пароль. В общем, операторы по умолчанию устанавливают "не имеет значения" для этого параметра. Но в случае, когда этот параметр является важным для оператора, он также затем должен принять имя пользователя/пароль СЕТИ СПОНСОРА. Такое определение обычно выполняют в определенном радиусе.

5. Прокси адрес: прокси адрес в GTP-U, автоматически выбираемый смартфоном, будет представлять собой прокси СЕТЬ СПОНСОРА. Таким образом, предпочтительно выполняют перенаправление прокси в прокси клиента двойного/множественного IMSI.

Домашняя страница (Интернет/MMS/WAP):

Выбирается автоматически устройством для домашней страницы СЕТИ СПОНСОРА. Таким образом, что перенаправление домашней страницы предпочтительно выполняется домашней сетью.

Изобретение не ограничено представленными примерными вариантами осуществления.

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

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

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

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

Хотя во всем тексте для каждого сокращения представлено полное наименование, ниже представлен список сокращений, и их полное наименование:

Изобретение относится к системам связи. Технический результат заключается в осуществлении надлежащей маршрутизации сообщения, в частности для сообщения, поступающего в смартфон и исходящего из него. В способе и системе для коррекции наименования точки доступа (APN) в сценарии роуминга данных GPRS при использовании сети оператора-спонсора и в способе и системе для направления сообщений GTP в надлежащий объект сети назначения после активации коррекции APN, если таковая требуется, фильтр GTP проверяет данные IMSI и APN на уровне GTP и, в зависимости от данных IMSI и APN, выполняет коррекцию APN и манипулирует параметрами GTP для обеспечения того, что контекст PDP будет правильно установлен между SGSN и GGSN, а дополнительные сообщения управления или данные GTP обходят приложение фильтра GTP. 4 н. и 12 з.п. ф-лы, 4 ил., 2 табл.

1. Способ коррекции наименования точки доступа (APN) в условиях роуминга при использовании сети оператора-спонсора, в котором обеспечивают фильтр протокола туннелирования GPRS (GTP), при этом, когда в фильтр GTP поступает сообщение «сформировать контекст протокола пакетных данных (PDP)» из обслуживающего узла поддержки GPRS выполняют проверку фильтром GTP данных международного идентификатора мобильного абонента (IMSI) и APN на уровне GTP, при этом

в зависимости от содержания данных IMSI и APN на уровне GTP фильтр GTP изменяет параметры GTP в плоскости управления GTP для:

направления трафика плоскости управления в надлежащее место назначения после коррекции APN, при этом

трафик плоскости данных устанавливают непосредственно между обслуживающим узлом поддержки GPRS (SGSN) и узлом поддержки шлюза GPRS (GGSN) или платформой двойного/множественного IMSI.

2. Способ по п. 1, в котором фильтр GTP модифицирует параметры GTP в плоскости управления GTP для

коррекции APN, если она применима,

направления трафика сообщения «сформировать контекст PDP» в плоскости управления GTP в следующие места назначения:

в GGSN сети спонсора, если IMSI в сообщении «сформировать контекст PDP» относится к абоненту сети спонсора,

в платформу двойного / множественного IMSI, если IMSI в сообщении «сформировать контекст PDP» относится к двойному / множественному IMSI абонента,

в GGSN оператора / активизатора мобильной виртуальной сети (MVNO/E), если IMSI в сообщении «сформировать контекст PDP» принадлежит MVNO/E,

при этом трафик плоскости данных устанавливают непосредственно между обслуживающим узлом поддержки GPRS и узлом поддержки шлюза GPRS или платформой двойного/множественного IMSI.

3. Способ передачи сообщений GTP в обслуживающий узел поддержки GPRS и из него в условиях роуминга при использовании сети оператора-спонсора, при этом

обеспечивают фильтр GTP между обслуживающим узлом поддержки GPRS и узлом поддержки шлюза GPRS или между обслуживающим узлом поддержки GPRS и платформой двойного/множественного IMSI, при этом фильтр GTP выполнен с возможностью активации логики потока вызова для направления трафика GPRS в обслуживающий узел поддержки GPRS, и

направления трафика плоскости управления GTP через фильтр GTP, когда трафик плоскости данных направляют непосредственно между первым и вторым узлом GPRS или между обслуживающим узлом поддержки GPRS и платформой двойного/множественного IMSI без прохода через фильтр GTP.

4. Способ по п. 3, в котором обеспечивают фильтр GTP между обслуживающим узлом поддержки GPRS и узлом поддержки шлюза GPRS.

5. Способ по п. 4, в котором передают сообщения GTP между обслуживающим узлом поддержки GPRS и GGSN MVNO/E, при этом MVNO/E использует IMSI спонсора, но имеет свой собственный уровень базовой сети, включающий в себя GGSN, при этом фильтр GTP выполнен с возможностью:

активации логики потока обработки вызова для направления трафика GTP между SGSN и GGSN MVNO/E,

направления только сообщения «сформировать контекст PDP» управления GTP через фильтр GTP, тогда как другие сообщения управления GTP, а также трафик плоскости данных направляют непосредственно между обслуживающим узлом поддержки GPR и GGSN MVNO/E без прохода через фильтр GTP.

6. Способ по п. 3, в котором обеспечивают фильтр GTP между обслуживающим узлом поддержки GPRS и платформой двойного/множественного IMSI.

7. Способ по п. 6, в котором для передачи сообщений GTP между обслуживающим узлом поддержки GPR и платформой двойного/множественного IMSI фильтр GTP выполнен с возможностью

активации логики потока вызова для направления трафика GTP между SGSN и платформой двойного/множественного IMSI,

направления трафика плоскости управления, относящегося к GPRS GTP через фильтр GTP, тогда как трафик плоскости данных направляют непосредственно между обслуживающим узлом поддержки GPRS и платформой двойного/множественного IMSI без прохода через фильтр GTP.

8. Способ по п. 5 или 7, в котором

при инициировании запроса системы доменных имен (DNS) из обслуживающего узла поддержки GPRS в сеть оператора-спонсора DNS возвращает IP-адрес для IP фильтра GTP и при поступлении следующего сообщения «сформировать контекст PDP» из обслуживающего узла поддержки GPRS в фильтре GTP выполняют проверку фильтром GTP данных IMSI и APN на уровне GTP, при этом

в зависимости от содержания данных IMSI и APN на уровне GTP фильтр GTP изменяет IP-адрес (источник и место назначения) в IP плоскости, но не изменяет адрес SGSN в сообщении вызова «сформировать контекст PDP» управления GTP, и

аналогично в сообщении отклика «сформировать контекст PDP» управления GTP, поступающем из платформы двойного/множественного IMSI или GGSN для MVNO/E, фильтр GTP не меняет IP-адрес GGSN на уровне GTP.

9. Способ по любому из пп. 1-7, в котором обеспечивают фильтр GTP в несущей обмена роумингом GPRS (GRX).

10. Способ по любому из пп. 1-7, в котором IMSI во входящем сообщении контекста PDP относится к абоненту сети спонсора, a APN относится к спонсору, фильтр GTP не выполняет никакой коррекции адреса SGSN на уровне GTP, ни APN, заполняет IP места назначения, равный IP GGSN сети спонсора на уровне IP и виртуализирует номер последовательности для поддержания состояния и возвращает отклик на сообщение «сформировать контекст PDP» к SGSN, вызвавшему сообщение «сформировать контекст PDP».

11. Способ по любому из пп.1-7, в котором IMSI во входящем сообщении контекста PDP относится к абоненту клиента двойного/множественного IMSI или сети MVNO, a APN относится к спонсору, фильтр GTP не выполняет никакой коррекции адреса SGSN на уровне GTP, заполняет IP места назначения, равный IP GGSN IP платформы двойного/множественного IMSI или IP MVNO на уровне IP, перенаправляет APN от спонсора в домашний APN и виртуализирует номер последовательности для поддержания состояния и возвращает ответ на сообщение «сформировать контекст PDP» к SGSN, вызвавшему сообщение «сформировать контекст PDP».

12. Способ по любому из пп.1-7, в котором IMSI во входящем сообщении контекста PDP относится к абоненту сети спонсора, a APN не относится к спонсору, а к корпоративному APN и фильтр GTP направляет сообщения к GGSN сети спонсора без коррекций на уровне IP или GTP.

13. Способ по любому из пп.1-7, в котором IMSI во входящем сообщении контекста PDP относится к абоненту клиента двойного/множественного IMSI или к сети MVNO, a APN относится не к спонсору, а к корпоративному APN, при этом фильтр GTP направляет сообщения к GGSN клиента двойного/множественного IMSI или сети MVNO без коррекций на уровне IP или GTP.

14. Система для коррекции наименования точки доступа (APN) в условиях роуминга при использовании сети оператора-спонсора, при этом система содержит фильтр GTP, выполненный с возможностью, при поступлении сообщения «сформировать контекст PDP» из обслуживающего узла поддержки GPRS в фильтр GTP, выполнять проверку по данным IMSI и APN на уровне GTP и в зависимости от содержания данных IMSI и APN на уровне GTP изменять параметры GTP в плоскости управления GTP, для

направления трафика плоскости управления, относящегося к GTP GPRS, через фильтр GTP, тогда как

трафик плоскости данных установлен непосредственно между обслуживающим узлом поддержки GPRS и узлом поддержки шлюза GPRS или платформой двойного/множественного IMSI.

15. Система для передачи сообщений GTP в обслуживающий узел поддержки GPRS (SGSN) в условиях роуминга при использовании сети оператора-спонсора, при этом

система содержит фильтр протокола туннелирования GPRS (GTP), обеспеченный между обслуживающим узлом поддержки GPRS и узлом поддержки шлюза GPRS или между обслуживающим узлом поддержки GPRS и платформой двойного/множественного IMSI, причем

фильтр GTP выполнен с возможностью

активации логики потока вызова для направления трафика GPRS в обслуживающий узел поддержки GPRS, и

направления трафика плоскости управления, относящегося к GTP GPRS, через фильтр GTP, когда трафик плоскости данных направлен непосредственно между первым и вторым узлом GPRS или между обслуживающим узлом поддержки GPRS и платформой двойного/множественного IMSI без прохода через фильтр GTP.

16. Система по п. 15, характеризующаяся тем, что выполнена с возможностью:

реконфигурирования при инициировании первой DNS запроса от обслуживающего узла поддержки GPRS в сеть оператора-спонсора посредством оператора-спонсора IP-адреса для оператора-спонсора в IP-адрес фильтра GTP, и

выполнения при поступлении последующего сообщения "сформировать контекст PDP" от обслуживающего узла поддержки GPRS в фильтре GTP проверки фильтром GTP данных IMSI и APN на уровне GTP, при этом

в зависимости от содержания данных IMSI и APN на уровне GTP фильтр GTP выполнен с возможностью изменения параметров GTP в плоскости управления GTP для

направления трафика плоскости управления, относящегося к GTP GPRS, через фильтр GTP, тогда как

трафик плоскости данных установлен непосредственно между обслуживающим узлом поддержки GPRS и узлом поддержки шлюза GPRS или платформой двойного/множественного IMSI,

и заполнения, при перенаправлении сообщения к узлу поддержки шлюза GPRS или к платформе двойного/множественного IMSI, своего собственного IP-адреса в качестве IP-адреса места происхождения.