Система и способ для коррекции apn в сообщениях gtp, ассоциированных с услугами передачи данных gprs, предлагаемыми мобильным оператором, используя сеть спонсора

Система и способ для коррекции apn в сообщениях gtp, ассоциированных с услугами передачи данных gprs, предлагаемыми мобильным оператором, используя сеть спонсора

Иллюстрации

Показать все

Реферат

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

Изобретение относится к способу для коррекции 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 принимает сообщение Сформировать