Область техники, к которой относится изобретение
Изобретение относится к телекоммуникациям, а в частности, к предложению архитектуры сети мобильной телефонной связи и связанных с ней сетевых элементов и сервисов.
Уровень техники, предшествующий изобретению
Традиционные сети мобильной телефонной связи строятся по принципу "страна-за-страной". Каждая страна, следовательно, имеет полный набор оборудования для всех сервисов, расположенных в пределах этой страны. Таким образом, не только, радиомачты и микроволновые ретрансляционные станции, элементы, которые должны быть расположены в той физической области, которую они обслуживают, располагаются в стране обслуживания, но также и все оборудование для передачи сигналов и для дополнительного обслуживания потребителей и выставления счетов располагаются в каждой стране. Этому подходу в глобальной сети недостает эффективности, и он может быть невыгоден для операторов и потребителей. Некоторую пользу могут принести подходы, которые дают потребителю возможность льготного доступа к множеству национальных сетей. Такого рода система раскрыта в более ранней заявке данного заявителя, имеющей номер WO 2011/036484. В ней раскрывается система, в которой некоторая центральная служба "IMSI-брокер (Брокер Международных идентификационных номеров абонентов мобильной связи)" приспособлен для снабжения SIM-модуля (модуля идентификации абонента) мобильного телефона новыми идентификационными номерами, которые требуются.
Было бы желательно дополнительно снизить издержки, направив дополнительно усилия на географические ограничения этого вида. Это перспективно, поскольку традиционные сети мобильной телефонной связи строятся таким образом. Сети, реализующие другие модели ведения бизнеса, не имеют таких географических ограничений. Например, Интернет-компании, такие как Amazon или Google, способны располагать инфраструктуру, которая обслуживает мир, в нескольких больших центрах обработки данных (дата-центрах). Такая централизация инфраструктуры не практична для сети мобильной телефонной связи. Нежелательно, чтобы телефонные звонки, например, от австралийского потребителя австралийскому потребителю проходили бы полностью через большой центр обработки данных, расположенный в другой географической области. Это увеличивало бы время задержки для телефонного звонка до недопустимого уровня.
Сущность изобретения
Авторы настоящего изобретения поняли, что имеется возможность распределить ресурсы, разделив их между локальными, региональными и центральными центрами обработки данных, таким образом, чтобы оптимизировать стоимость и качество сети, не приводя при этом к недопустимому времени задержки в отдельных географических областях.
Задача данного изобретения заключается в том, чтобы предложить новую форму архитектуры мобильной связи, которая разделяет сетевые элементы, системы операционной поддержки (OSS-системы) и системы поддержки ведения бизнеса (BSS-системы) между локальными, региональными и центральными центрами обработки данных. В одном широком аспекте, такого рода система имеет системы оперативной поддержки и системы поддержки ведения бизнеса, которые, по меньшей мере, частично, содержатся в региональных или центральных центрах обработки данных, тогда как сетевые элементы содержат локальные или региональные центры обработки данных. Локальные центры обработки данных поддерживают единственную страну, региональные центры обработки данных поддерживают множественные страны, тогда как центральный центр обработки данных поддерживает международную сеть. В дополнительном аспекте, система для предоставления сервисов мобильной связи по всему миру может содержать центральный сервер, приспособленный для выполнения функций OSS-систем и BSS-систем, и один или более региональных серверов и/или еще один или более локальных (национальных) серверов, приспособленных для предоставления аудио сервисов и сервисов по передаче данных.
В первом аспекте, изобретение предлагает способ управления сетью мобильной связи для того, чтобы предоставлять абоненту сервисы сотовых телекоммуникаций в некотором множестве стран, причем способ, содержащий этапы, на которых: предоставляют некоторый первый набор упомянутых сервисов сотовых телекоммуникаций из некоторого центрального узла, охватывающего все страны из этого множества стран; и предоставляют некоторый второй набор упомянутых сервисов сотовых телекоммуникаций из некоторого множества региональных узлов, причем каждый региональный узел предоставляет второй набор сервисов сотовых телекоммуникаций некоторому подмножеству из этого множества стран.
Этот подход делает возможной оптимизацию издержек и качества сети. Использование этой архитектуры делает возможным использовать для создания всей сети меньшее количество компонентов. Кроме того, поскольку требуется меньшее количество компонентов, то каждый из них может быть большим, лучшего качества и с увеличенным резервированием. Поскольку компоненты могут обслужить мир или группы стран, а не отдельную страну, то балансировка нагрузки сети может следовать за солнцем. Например, передающие сигналы серверы могли бы не использоваться лондонскими потребителями в то время, когда токийские потребители экстенсивно используют этот ресурс.
Можно избежать проблем со временем задержки, поскольку сетевые операции, необходимые для поддержания реального общения между двумя сторонами, в частности, для поддержания речевого телефонного звонка между двумя сторонами, могут быть выполнены локальным центром обработки данных, поддерживающим обе стороны, или соответствующими локальными центрами обработки данных для каждой стороны. Операции, относящиеся к телефонному звонку, которые не затрагивают время задержки, (такие как другие функции операционной поддержки или поддержки ведения бизнеса, выполняемые OSS-системой или BSS-системой) могут выполняться региональным центром обработки данных или центральным центром обработки данных.
В еще более широком аспекте, сеть может быть организована для резервирования таким образом, чтобы центр обработки данных, связанный с одной географической областью, мог поддерживать другую географическую область в случае неисправности. В некоторых вариантах организации, сети снабжены локальными операторами, с взаимодействием с локальными сетями и функциями BSS-систем и OSS-систем, предоставляемых в центрах обработки данных. Центры обработки данных могут быть соединены выделенной магистральной линией связи.
Краткое описание чертежей
Конкретные варианты воплощения изобретения будут описаны ниже, в порядке примера, со ссылкой на прилагаемые чертежи, на которых:
на фиг. 1 показана приводимая в качестве примера схема сети мобильной телефонной связи, которая простирается на ряд стран;
на фиг. 2 показано логическое распределение сетевых активов, приспособленное для того, чтобы поддерживать международную сеть мобильной связи, соответствующую одному варианту воплощения изобретения;
на фиг. 3 показан пример функций, предоставляемых в региональном центре обработки данных, соответствующий одному варианту воплощения изобретения;
на фиг. 4 показана возможность соединения между сетевыми элементами, соответствующая одному варианту воплощения изобретения;
на фиг. 5 показан один вариант воплощения изобретения, показывающий физические соединения;
на фиг. 6 показан один вариант воплощения изобретения, показывающий архитектуру системы SS7 (Системы сигнализации по общему каналу №7);
на фиг. 7 показан один вариант воплощения изобретения, показывающий подход к передаче сигналов в случае передачи сигналов подсистемы ISUP (абонентской подсистемы передачи сигналов для цифровой сети с интегрированным обслуживанием);
на фиг. 8 показан один вариант воплощения изобретения, показывающий подход к передаче сигналов в случае передачи сигналов подсистемы SCCP (подсистемы управления соединением для передачи сигналов);
на фиг. 9 показан один вариант воплощения изобретения, показывающий одноранговую IP-связь (связь по протоколу межсетевого взаимодействия между одноранговыми устройствами) и трафик данных;
на фиг. 10 показан один вариант воплощения регионального центра обработки данных;
на фиг. 11 показана схема для прямого межсоединения с MNO-оператором (оператором сети мобильной связи);
на фиг. 12 показана архитектура с предоставлением множественного GRX (глобального роуминга);
на фиг. 13 показана схема для сервисного межсоединения;
на фиг. 14-16 показаны приводимые для справки последовательности операций при телефонном вызове;
на фиг. 17 показаны дополнительные аспекты плана передачи сигналов;
на фиг. 18 показана схема для возможности соединения по SIP-протоколу (Протоколу инициирования сеанса связи);
на фиг. 19 показана обобщенная последовательность операций для переносимости номеров мобильной связи;
на фиг. 20 показана модель сообщения для переносимости номеров мобильной связи;
на фиг. 21 показана обобщенная последовательность операций для переносимости номеров мобильной связи;
на фиг. 22 показан шаблон повторного использования для переносимости номеров мобильной связи;
на фиг. 23 показана таблица классификации номеров;
на фиг. 24 показана схема для классификации номеров;
на фиг. 25 изображена модификация схемы для классификации номеров; и
на фиг. 26-28, показаны различные модели для определения GGSN-узла (шлюзового узла поддержки GPRS (Общего сервиса пакетной радиопередачи)) для АР-точки.
Детализированное описание предпочтительных вариантов воплощения изобретения
На фиг. 1 показана приводимая в качестве примера схема сети мобильной телефонной связи, которая простирается на ряд стран, вместе с центрами обработки данных, связанными с этой сетью. Центры обработки данных присутствуют в Лондоне, Амстердаме, Гонконге, Сиднее, Нью-Йорке и Лос-Анджелесе - эти центры обработки данных в описываемом варианте воплощения изобретения имеют региональные и/или глобальные функции (чисто национальные центры обработки данных не показаны на фигуре). Эти центры поддерживают национальные сети в некотором множестве стран, обычно посредством взаимодействия с локальными операторами в этих странах. Как будет описан ниже, различные центры обработки данных могут предоставлять различные функциональные возможности, при этом некоторые центры обработки данных действуют в качестве локальных центров обработки данных, поддерживающих только одну национальную сеть (или, возможно, некоторое множество национальных сетей для одной страны), некоторые центры обработки данных действуют в качестве локальных центров обработки данных, поддерживающих национальные сети в более чем одной стране, и, по меньшей мере, один центр обработки данных действует в качестве глобального центра обработки данных таким образом, чтобы поддерживать все сети в отношении, по меньшей мере, некоторых сервисов. Один центр обработки данных может иметь множество ролей: он может, например, действовать в качестве локального центра обработки данных, для некоторых целей, в качестве регионального центра обработки данных, для других целей, и в качестве глобального центра обработки данных, для других целей.
Это разделение задач более подробно показано на фиг. 2, на которой показано логическое распределение сетевых активов для того, чтобы поддерживать международную сеть мобильной связи. Как можно видеть на фиг. 2, в этом варианте воплощения изобретения лондонский и амстердамский центры обработки данных действуют как глобальные центры обработки данных, поддерживающие функции OSS-системы (системы операционной поддержки) и BSS-системы (системы поддержки ведения бизнеса), которые не влияют на время задержки для индивидуальной связи. Эти функции могут включать в себя централизованное выставление счетов, управление отношениями с потребителями, управление устранением неисправностей и управление качеством функционирования сети. Все шесть центров обработки данных действуют в качестве региональных центров обработки данных, предоставляя основу для глобально децентрализованной и глобально эластичной сети. Это, там, где уместно, позволяет локализовать функции по отношению к регионам, и также предоставляет сети возможность масштабируемости и гибкости, позволяя добавлять на региональном уровне новые центры обработки данных, в случае, когда спрос становится достаточно высоким, и позволяя переключать поддержку между одним и другим региональными центрами обработки данных в случае, когда это поддерживает спрос наиболее эффективным образом.
Как показано на фиг. 2, эти региональные центры обработки данных могут быть использованы для поддержания роуминга в различных географических регионах. В данном случае, лос-анджелесский и нью-йоркский центры обработки данных поддерживают роуминг на американских континентах, лондонский и амстердамский центры обработки данных поддерживают роуминг в регионе ЕМЕА (Европа, Ближний Восток и Африка), а гонконгский и сиднейский центры обработки данных поддерживают роуминг в Азиатско-Тихоокеанском регионе. Эти центры обработки данных взаимодействуют с национальными операторами, которые могут представлять собой различные национальные операторы в каждой географической области, и могут включать в себя множественных операторов в одной географической области. В то время как глобальные и региональные центры обработки данных (и, в предпочтительном варианте, выделенная магистральная линия связи между ними) обычно должны находиться под общим управлением, сети национальных операторов обычно не должны. SIM-модуль абонента (Модуль идентификации абонента) (в предпочтительном варианте предоставляемый в соответствии с подходом, описанным более ранней заявке данного заявителя, имеющей номер WO 2011/036484) может быть снабжен IMSI-номерами (Международными идентификационными номерами абонента мобильной связи) для того, чтобы осуществлять доступ к этим множественным национальным сетям, причем все эти IMSI-номера ассоциативно связаны с учетной записью пользователя, ассоциативно связанной с глобальной сетью, содержащей эти глобальные и региональные центры обработки данных.
Фиг. 3 предоставляет указание на функции, предоставляемые глобальными и региональными центрами обработки данных. Полный диапазон функций OSS-систем и BSS-систем предоставляется в двух глобальных центрах обработки данных в Лондоне и Амстердаме, включая в себя такие сетевые функции, как предоставление Регистра "домашнего" местоположения (HLR-регистр). Предоставление этих функций в каждом глобальном центре обработки данных обеспечивает резервирование на случай неисправности. Региональные центры обработки данных в этом варианте воплощения изобретения снабжены только более ограниченным набором функций, предназначенным для поддержания регионального трафика связи - они представляют собой GGSN (Шлюзовой узел поддержки GPRS (Общего сервиса пакетной радиопередачи)), делающий возможным переключение между GPRS-сетями и сетями с пакетной коммутацией, такими как сеть "Интернет", и MGW (Шлюз мультимедийных данных), для преобразования цифровых мультимедийных потоков данных между различными типами сетей. Предоставление этих функций на региональном уровне, а не на глобальном уровне, устраняет проблемы времени задержки, которые возникали бы в том случае, если бы эти функции предоставлялись на глобальном уровне. Основные узлы управления передачей сигналов располагаются в глобальных центрах обработки данных, но узлы обработки мультимедийных данных располагаются близко к национальным сетям и локальным выходам в сеть "Интернет".
В показанной конкретной схеме, узлы управления политикой и начислением платы (PCRF (Функция правил политики и начисления платы) и OCS) располагаются в глобальных центрах обработки данных. Логично расположить их совместно с системами BSS и CRM (Управления отношениями с потребителями), поскольку они глубоко связаны. В глобальных центрах обработки данных можно наиболее удобным образом предусмотреть и другие интерфейсы базы данных. В региональных центрах обработки данных, в дополнение к узлам обработки мультимедийных данных, могут быть расположены и некоторые другие управляющие узлы, которые релевантны географическому месту расположения.
Трафик управляющих данных и передачи сигналов, обмен которым осуществляется между глобальными и региональными центрами обработки данных (например, Gx- и Gy-интерфейсами) транспортируется по общей магистральной линии связи, приводимая в качестве примера схема магистральной линии связи, связывающая центры обработки данных, показана на фиг. 4. На фиг. 4 также показана возможность соединения между сетевыми элементами, которая обеспечивает сервис резервирования и масштабирования для сети. Трафик ОАМ (Операции, администрирование и управление) посылается в глобальный центр обработки данных, в котором располагаются ОАМ-платформы. Все требующиеся возможности соединения для трафика реализуются посредством общей магистральной линии связи. Она может быть предоставлена как виртуальная частная сеть, такая как VPLS. На показанной схеме, в каждом центре обработки данных реальную физическую возможность соединения обеспечивают, в целях резервирования, две основные несущие. Все типы трафика, требующего перехода между центрами обработки данных, связаны за исключением синхронизаций ключевых баз данных (HLR-регистра, системы начисления платы в режиме "он-лайн"), которые снабжены выделенными соединениями. Внешние межсоединения обеспечиваются в виде модели "ступица и спицы" в каждом центре обработки данных. Трафик может быть разделен внутри магистральной линии связи с использованием различных VRF (виртуальных маршрутизации и переадресации).
На фиг. 10 показан типичный состав для регионального центра обработки данных, который также может рассматриваться в качестве удаленного Ядра мобильной пакетной связи. Централизованно предоставляемые сервисы, такие как политика и начисление платы предоставляются по магистральной линии связи из центрального (или, возможно, другого регионального) центра обработки данных. Сам же центр обработки данных содержит GGSN-узел и другие сетевые элементы, которые уместно предусматривать в региональной географической области, а не централизованно. В таком случае региональный центр обработки данных предоставляет локальный Интернет, роуминг через глобальный роуминг (GRX) и прямые соединения с оператором (соединения MNO Direct).
На фиг. 5 показана одна схема соединения для голосовой связи. Она представляет собой прямое соединение между региональным центром обработки данных и MNO (Оператором сети мобильной связи). Как можно заметить, к MNO-оператору могут, посредством надлежащих переключения и сетей передачи данных, подсоединяться различные региональные центры обработки данных, так что в случае необходимости MNO-оператор мог быть поддержан больше чем одним региональным центром обработки данных. На фиг. 6-8, показаны альтернативные схемы межсоединений для голосовой связи. На фиг. 6 показана архитектура линии SS7 (Системы сигнализации по общему каналу №7), показывающая соединению между глобальными центрами обработки данных и индивидуальными STP-пунктами (Пунктами передачи сигналов) линии (SS7) связи. Связанная с этим передача сигналов подсистемы ISUP (абонентской подсистемы передачи сигналов для цифровой сети с интегрированным обслуживанием) показана на фиг. 7, а передача сигналов подсистемы SCCP (подсистемы управления соединением для передачи сигналов) показана на фиг. 8. На фиг. 9 показана схема соединения для данных.
Аспекты приводимой в качестве примера схемы сети и приводимых в качестве примера схем передачи сигналов будут теперь описаны более подробно.
Может быть предусмотрен ряд различных межсоединений доступа. Предпочтительным подходом является подход для прямого межсоединения с MNO-оператором, как это показано на фиг. 11. На показанной схеме все данные, обменен которыми осуществляется между CNO-оператором (Оператором базовой сети, который ответственен за глобальные и региональные центры обработки данных) и MNO-оператором, будь то данные, относящиеся к плоскости управления или плоскости пользователя, проходят по линиям прямых межсоединений. Эти линии связи, для целей резервирования, могут быть предоставлены различными провайдерами-третьими лицами, и могут реализовывать одноранговую связь по протоколам BGP/IP (Протоколу пограничного шлюза/протоколу межсетевого взаимодействия) между операторами. Предпочтительно, чтобы каждый MNO-оператор был, в целях резервирования, соединен с двумя различными центрами CNO-операторами, как это было описано выше.
Другие применимые схемы могут включать в себя спонсируемый роуминг (которым может управлять некоторый MVNO-оператор (Оператор виртуальной сети мобильной связи), не имеющий своего собственного диапазона номеров, но использующий некоторый поддиапазон IMSI-номеров (Международных идентификационных номеров абонентов мобильной связи), предоставленный некоторым спонсором) или роуминг с использованием GRX-концентратора (концентратора глобального роуминга). GRX был указан GSMA в качестве нормального способа межсоединения операторов GSM (Глобальной системы мобильной связи) для стандартного международного роуминга. Операторы объявляют другим операторам свои идентификаторы и планы присвоения номеров посредством документов, именуемых как IR21. Фактическая инфраструктура для этого межсоединения "многих - со - многими" снабжена несущими, функционирующими как концентраторы. На фиг. 12 показана архитектура высокого уровня с предоставлением множественных GRX.
Сервисное межсоединение относится к возможности соединения посредством межсоединения и также к частным сетям передачи данных, таким как сеть BlackBerry. Возможность соединения посредством межсоединения предоставляется Ядром мобильной пакетной связи, эту возможность делает доступной для пользователей мобильной связи GGSN-узел, но реализуется она посредством основной магистральной линии связи.
Схема для этого показана на фиг. 13. Каждый центр обработки данных имеет свое собственное соединение с сетью "Интернет", обычно обеспечиваемое двумя (для целей резервирования) локальными ISP-провайдерами (провайдерами Интернет-услуг). Это означает, что не требуется никакого транспортировки Gi-интерфейса по магистральной линии связи между узлами центров обработки данных. Это уменьшает время задержки доступа и требования к ширине полосы пропускания магистральной линии связи, и упрощает топологию.
Соединение к локальными ISP-провайдерами осуществляется по прямым межсоединениям, реализуемым основной магистральной линией связи. В этих соединениях используется публичное пространство IP-адресов CNO-оператора. Также, если требуется, перед выходом трафика в сеть "Интернет" основная магистральная линия связи выполняет NAT (преобразование сетевых адресов)/РАТ для доступа пользователя мобильной связи. Сервис DNS (сервера доменных имен) сети "Интернет" выполняется локальными ISP-провайдерами, так что CNO-оператору не требуется внутренняя система доменных имен для разрешения Интернет-адреса.
При этой топологии, CNO-оператор предоставляет доступ в локальную сеть "Интернет" там, где присутствуют GGSN-узлы. Для поддержания ожиданий доступа в локальную сеть "Интернет" может потребоваться принять меры для того, чтобы предоставить сервисы, основанные на указании месторасположения. Например, польский пользователь мог бы ожидать, осуществляя доступ в сеть "Интернет" того, что Google (или другие провайдеры веб-сайтов), чтобы автоматически перенаправлять его доступ на польский язык. Это обычно будет делаться на основе IP-адреса пользователя.
Для возможности BlackBerry-соединения необходимо достигнуть одноранговой связи с POI (точками интерфейса) BlackBerry. Это может быть сделано множеством способов, таких как посредством прямого межсоединения, посредством межсоединения по протоколу IPX (межсетевого пакетного обмена) или посредством GRE-туннелирования.
Теперь опишем индивидуальные сетевые элементы. GGSN-узел (Шлюзовой узел поддержки GPRS (Общего сервиса пакетной радиопередачи)) может иметь встроенную Функцию применения политики и начисления платы (PCEF-функцию), соответствующую 3GPP TS 23.203 и 29.212 (Техническим спецификациям 23.203 и 29.212 Проекта партнерства третьего поколения), для которой основное функционирование заключается в том, чтобы поддерживать инициирующие триггеры события, сообщать статистику трафика (например, объем, время) и применять показатель QoS (качества обслуживания) и согласно тому, что предписано Сервером управления политикой (Функцией правил политики и начисления платы, PCRF-функцией). Могут также быть сконфигурированы локальные правила, и способность Осведомленности о сервисе, используемая для обнаружения того, какой сервис используется, так, чтобы политика и начисление платы могли быть применены на уровне потока данных. Может быть обеспечено применение политики, такое как динамическое управление QoS-качеством однонаправленного канала передачи данных, управление пропусканием сервиса и потока данных и перенаправление трафика как на уровне L3, так и на уровне HTTP-протокола (Протокола для передачи гипертекста). Может быть использовано полное внутреннее аппаратное резервирование для поддержания эластичности, например, за счет переключения между множественными сервисными контактами с использованием модели резервирования "активное состояние/резервное состояние". Это может быть основано на группах, которые содержат пару из активного/резервного элементов восстановления. Группы восстановления используются для того, чтобы управлять ресурсами (например, дисковыми файловыми системами или IP-адресами), которые могут быть связаны с группами восстановления. Когда, например, с группой восстановления связан IP-адрес, он становится подвижным ресурсом, которым управляют функции сервисов высокой готовности (HAS-сервисов) и который они распределяют элементам восстановления. Активный в текущий момент времени элемент восстановления в группе восстановления владеет подвижным ресурсом, и если активный элемент восстановления выходит из строя, то функциональные возможности подвижного ресурса переключаются на резервный элемент восстановления. Для того чтобы обеспечить непрерывность резервирования и трафика, каждый тип трафика будет помещен в двух виртуальных локальных сетях, сконфигурированных на отдельных портах.
Серверы, расположенные в региональных центрах обработки данных могут предоставлять и другие сетевые функции, такие как разрешение APN-имени (имени точки доступа) и AAA-сервисы. Резервирование может поддерживаться оборудованием или на уровне сервисов.
Управление политикой и начисление платы предусматриваются в центральном центре (центральных центрах) обработки данных и, в предпочтительном варианте, также используют аппаратное резервирование на случай обвала (OCS представляет собой более сложный случай, вовлекающий сеть взаимосвязанных систем, которые могут использовать множественные стратегии). Централизованно могут предоставляться и другие сервисы, такие как поддержка сети.
Сервисное резервирование также является важным, и достигается посредством планирования сценариев преодоления отказов, включающих в себя отказ элемента сети, отказ линии межсоединения и отказ узла. Как правило, сервисное преодоление отказов будет включать в себя замену центра обработки данных, предоставляющего сервис. Это достижимо с этой архитектурой, поскольку Сервис мобильной связи с передачей пакетных данных реализуется, для учреждения сеанса связи/однонаправленного канала передачи данных, независимо, в каждом месте расположения GGSN-узла (Шлюзового узла поддержки GPRS (Общего сервиса пакетной радиопередачи)).
Также желательно резервирование в Gp-интерфейсе, который представляет собой интерфейс межсоединения между базовыми сетями (PS-домена) двух различных Операторов. Он соединяет между собой посещаемую сеть (SGSN-узел (Обслуживающий узел поддержки GPRS (Общего сервиса пакетной радиопередачи))) и "домашнюю" сеть (GGSN-узел для рассматриваемого CNO-оператора). Он включает в себя интерфейс DNS, используемый посещаемым SGSN-узлом и/или DNS, для запроса "домашнего" DNS-сервера для разрешения APN-имени (в основном для выбора GGSN-узла, который будет предоставлять сервис). Этот запрос направляется либо через GRX, либо через линии прямого межсоединения с MNO-операторами - разрешение APN-имени (имени точки доступа) будет различным в обоих сценариях. По этой причине каждый из двух DNS-серверов в каждом центре обработки данных принадлежит различным DNS-кластерам. После разрешения APN-имени выбирается GGSN-узел для того, чтобы обрабатывать этот конкретный PDP (Протокол пакетных данных). Выбор GGSN-узла зависит от DNS, который запрашивается, и рассматриваемого сценария вызова. Резервирование достигается посредством конфигурации, основанной на IMSI-номере (Международном идентификационном номере абонента мобильной связи) пользователя, типе доступа и конфигурации DNS.
Резервирование по Gi-интерфейсу реализуется для сервисов передачи данных. Внутреннее резервирование обеспечивается на уровне GGSN-узла, при этом возможность соединения с локальными ISP-провайдерами (провайдерами Интернет-услуг) обеспечивается основной магистральной линией связи на уровне возможности соединения, использующем резервированные географические конечные точки и различных провайдеров линий связи. Для DNS-сервиса сети "Интернет", многократно используются DNS-серверы ISP-провайдеров, сконфигурированные в сервисе APN-имен. Каждый ISP-провайдер предоставляет два DNS-сервера для резервирования. Предпочтительно, чтобы доступ в сеть "Интернет" всегда предоставлялся в той же локальности, что и обслуживающий GGSN-узел, даже в сценарии преодоления отказа, -это означает, что не должно быть никакого трафика по сети "Интернет" между центрами обработки данных, проходящего по магистральной линии связи.
Резервирование в интерфейсе Gy (для начисления платы в режиме "он-лайн" за сервисы мобильной связи с передачей пакетных данных) и в интерфейсе Gx (для управления политикой сервисов мобильной связи с передачей пакетных данных) обеспечивается с использованием активных/активных или активных/резервных конфигураций в двух глобальных центрах обработки данных.
Теперь опишем предоставление сетевых сервисов. Сервис мобильной связи с передачей пакетных данных реализуется в точках действия сервиса (АР-точках). Они идентифицируются своим именем, следовательно, именем точки доступа (или APN-именем). APN-имя определяет обработку сервиса в GGSN-узле, так же как и обеспечиваемые характеристики сервиса. Эти характеристики включают в себя: выбор экземпляра маршрута; распределение IP-адреса (адреса по протоколу межсетевого взаимодействия) пользовательскому оборудованию (IP-пулы); аутентификацию; учет и начисление платы; применение политики; ширину полосы пропускания и управление QoS (Качеством обслуживания); и управление доступом.
APN-имя конфигурируется в профиле абонента в HLR-регистре), и подается в SGSN-узел при успешном PS-прикреплении. После этого оно используется пользовательским оборудованием для запроса сеанса передачи данных (в контексте PDP-протокола (Протокола пакетных данных)), проверяется SGSN-узлом в соответствии с профилем, принятым из HLR-регистра, разрешается посредством DNS-сервера Gn/Gp, и посредством передачи сигналов по GTP-протоколу передается в GGSN-узел, который после этого обрабатывает этот запрос вместе с другими элементами базовой сети, подобными OCS и PCRF.
На фиг. 26-28, показаны различные моделям для определения GGSN-узла для APN-имени.
На схеме на фиг. 26 показано, что, когда мобильная станция (MS-станция) регистрируется в SGSN-узле, HLR-регистр снабжает ее APN-именем, дозволенным для нее. ТЕ-элемент (наделенный доверием элемент) мобильной станции выбирает APN-имя для этой мобильной станции для того, чтобы запрашивать PDP-протокол (Протокол пакетных данных). SGSN-узел осуществляет разрешение этого APN-имени, исходя из DNS-сервера (обозначенного как 3) HPLMN, для того, чтобы узнать, с каким GGSN-узлом должен быть установлен сеанс связи по PDP-протоколу. Здесь, осуществлено автоматическое разрешение этого имени на узел GGSN 1, этот GGSN-узел принимает PDP-протокол, и доступ в сеть "Интернет" установлен. Этот подход не дает возможность осмысленного выбора GGSN-узла (например, на основе места расположения мобильной станции).
На схеме на фиг. 27 показано, что когда мобильная станция (MS-станция) регистрируется в SGSN-узле, HLR-регистр вновь снабжает ее APN-именем, дозволенным для нее. ТЕ-элемент (наделенный доверием элемент) мобильной станции выбирает APN-имя для этой мобильной станции для того, чтобы запрашивать PDP-протокол (Протокол пакетных данных). SGSN-узел осуществляет разрешение APN-имени из DNS-сервера (обозначенного как 3) HPLMN, для того, чтобы узнать, с каким GGSN-узлом должен быть установлен сеанс связи по PDP-протоколу. Автоматического разрешения этого имени на узел GGSN 1 не производится, он использует Виды и зоны DNS для выбора GGSN-узла в соответствии с тем SGSN-узлом, из которого исходит запрос. Выбранный GGSN-узел принимает PDP-протокол, и доступ в сеть "Интернет" установлен. Этот подход дает возможность большей гибкости и более подходящего выбора GGSN-узла на основе запрашивающего SGSN-узла.
На схеме на фиг. 28 показано, что когда мобильная станция (MS-станция) регистрируется в SGSN-узле, HLR-регистр снабжает ее группой дозволенных APN-имен, показанной здесь как имена: с APN1 по APNx, ассоциативно связанной с APN-именем наделенного доверием элемента. ТЕ-элемент сообщает и сверяет с SIM-модулем то, может ли быть установлен сеанс передачи данных с исходным APN-именем, и SIM-модуль запрограммирован таким образом, чтобы отображать исходное APN-имя на любое APN-имя из числа имен: с APN1 по APNx, в зависимости от критериев конфигурации, таких как сети, в которой зарегистрирована эта мобильная станция. Мобильная станция после этого представляет запрос PDP-протокола с преобразованным APN-именем, SGSN-узел осуществляет разрешение правильного APN-имени из DNS-сервера HPLMN для того, чтобы идентифицировать правильный GGSN-узел, и доступ в сеть "Интернет" установлен, как и ранее. Эта модель является предпочтительной, поскольку она дает возможность выбора GGSN-узла, исходя из любых подходящих параметров, получаемых от SIM-модуля или в мобильном оборудовании. Это также дает HPLMN больше контроля в случае, когда имеются специальные предпочтения в отношении роуминга или действующие соглашения - это может позволить, например, регионализацию трафика данных за счет использования узла US GGSN (Шлюзовой узел поддержки GPRS в Соединенных Штатах) для всего трафика данных в североамериканском регионе.
Имя APN выбирается таким образом, чтобы указывать конкретный сервис, на который подписался пользователь, и должно быть известно различными платформами, вовлеченным в аутентификацию, авторизацию, учет и начисление платы, и управление сеансом связи.
GGSN-узел может поддерживать функциональные возможности Осведомленности о сервисе, предусматривающие как SPI-инспекцию (Поверхностную инспекцию пакетов), так и DPI-инспекцию (Глубокую инспекцию пакетов), применимые по правилам РСС. Сервис мобильной связи с передачей пакетных данных может предоставлять однонаправленный канал передачи данных для MMS (Сервиса передачи мультимедийных сообщений). Если требуется, то в GGSN-узле может быть обеспечен законный перехват для сервисов передачи данных. Управлением политикой и начисление платы обрабатываются в GGSN-узле внешними серверами, использующими, соответственно, интерфейсы Gx и Gy.
Вышеописанная архитектура может быть с легкостью модифицирована для сети, использующей стандарт LTE (Долгосрочной эволюции). Стандарт LTE использует вместо HLR-регистра Сервер "домашних" абонентов (HSS-сервер): HLR-регистр может быть заменен HSS-сервером, или эти два сервера могут быть реализованы параллельно. Эта архитектура может также быть с легкостью обновлена для того, чтобы поддерживать парадигмы роуминга данных по стандарту LTE, относящимся к "Домашней" маршрутизации и Локальному "прорыву". Аналогичным образом, эта архитектура может быть с легкостью приспособлена для того, чтобы поддерживать протокол IPv6.
На фиг. 14-16, показаны приводимые для справки последовательности операций при телефонном вызове.
Ниже дополнительно описываются дополнительные аспекты плана передачи сигналов. За передачу сигналов отвечают два типа сетевых узлов: MSS-система (Система Сервера MSC (Центра коммутации мобильной связи)) и STP-пункт (Пункт передачи сигналов)-они показаны на фиг. 17. Они ответственны за голосовую ISUP-подсистему (абонентскую подсистему передачи сигналов для цифровой сети с интегрированным обслуживанием) и передачу сигналов мобильности (SCCP-подсистему (подсистему управления соединением для передачи сигналов). SCCP-маршрутизация требуется для ответа на запрос Обновления информации о месте расположения, поступающий от HLR-регистра CNO-оператора в MSS-систему подключенной партнерской сети, где абоненты CNO-оператора будут выполнять Обновление данных о месте расположения. Плоскость управления между MSS-системой и MGW-шлюзом состоит из H.248/MEGACO и M3UA/SIGTRAN. Интерфейс Н.248 используется для управления ресурсами и других функций управления между MSS-системой и MGW-шлюзом, где MSS-система имеет функцию управления MGW-шлюзом. SIGTRAN-интерфейс используется для маршрутизации сообщений передачи сигналов между MSS-системой и MGW-шлюзом, где MGW-шлюз действует в качестве Шлюза передачи сигналов между MSS-системой и любым внешним сетевым элементом.
Протокол ISUP используется для соединения с различными сетями. Маршрутизация передачи сигналов к Национальным и Международным межсоединениям будет на Глобальном заголовке для трафика SCCP и на SPC для трафика ISUP.
Для создания и управления мультимедийными сеансами связи между двумя или более участниками может быть использован Протокол Инициирования Сеанса связи (SIP-протокол). Общая цель SIP-протокола заключается в том, чтобы поддерживать передачу Голоса по IP-протоколу (VoIP) и обеспечивать то, чтобы будущие VoIP-сервисы были полностью основаны на Интернете. Этот протокол может работать с другими характеристиками MSC-сервера (MSS) и реализует Функцию управления шлюзом мультимедийных данных (MGCF-функцию) в MSS-системе. Возможности соединения по SIP-протоколу показаны на фиг. 18.
SCTP-протокол (Протокол передачи сигналов управления потоком данных) представляет собой уровень над физическим уровнем IP-протокола, который будет нести трафик как M3UA, так и Н.248. MSS-система and STP-пункты действуют в качестве шлюза SCCP-подсистемы в большинстве связанных с мобильностью событий. Трафик SCCP-подсистемы, берущий свое начало от MNO-оператора отправят элементам платформы внутреннего сервиса, основываясь на Глобальном заголовке (GT-заголовке), преобразованном в Код пункта назначения (DPC-код) и Номер подсистемы (SSN-номер).
Таким образом, для того, чтобы создать надлежащий уровень SCTP-протокола между MSS-системой и MGW-шлюзом необходимо решить две основные задачи. Они представляют собой создание наборов параметров SCTP-протокола для Н.248 и M3UA со сходными значениями параметров в MSS-системе и MGW-шлюзе, и создание множественной адресации по SCTP-протоколу для звеньев передачи сигналов в MSS-системе и MGW-шлюзе. Множественная адресация будет использоваться во всех ассоциациях SCTP-протокола. Хост имеет множественную адресацию в том случае, когда к нему можно обращаться по множественным IP-адресам. SCTP-протокол может использовать оба интерфейса таким образом, что один функционирует в качестве основного маршрута, а другой - в качестве вспомогательного маршрута. Обычно трафик передачи сигналов идет по основному маршруту, а если имеет место неисправность, то SCTP-протокол начнет повторную отправку по вспомогательному маршруту. Это обеспечивает то, что, если один из маршрутов разорван, никакие сообщения не будут потеряны.
Стратегия межсоединения для следования этому заключается в нижеследующем.
Для MNO-оператора, подсоединенного по межсоединениям по IP-протоколу, межсоединения по IP-протоколу соединены с MSS-системой, для плоскости управления, посредством SIP-протокола, и с MGW-шлюзом, для плоскости пользователя, посредством RTP-протокола (Протокола транспортного уровня в реальном масштабе времени), при этом трафик обеспечивающей мобильность маршрутизации подсистемы SCCP (подсистемы управления соединением для передачи сигналов) базируется в упакованном виде на линии (SS7) связи по IP-линии связи по протоколу "SIGTRAN" между CNO оператором и сетью партнеров.
Для MNO-оператора, подсоединенного по TDM-межсоединению, TDM-межсоединения будут соединены с плоскостью управления MSS-системы с использованием передачи сигналов ISUP-подсистемы. Для функций плоскости пользователя, в MGW-шлюзе будут установлены соединения E1 по STM-1. TDM-межсоединения будут иметь возможности соединения по передаче сигналов с MSS-системой через MGW-шлюз, который действует в качестве шлюза передачи сигналов. Будет создана обеспечивающая мобильность маршрутизация подсистемы SCCP, базирующаяся на Глобальном заголовке, по направлению к сети партнеров по межсоединению. Маршрутизация SCCP-подсистемы требуется для ответа об Обновлении данных о месторасположении, поступающего от HLR-регистра CNO-оператора в MSS-систему сети партнеров по межсоединению, где абоненты CNO-оператора будут выполнять Обновление данных о месте расположения. Передачей сигналов в MGW-шлюзе управляет MSS-система по протоколу SIGTRAN. Она обеспечивается по интерфейсным звеньям передачи сигналов (именуемым как ISU-звенья), сконфигурированным в MGW-шлюзе. TDM-межсоединения будут иметь соединения по передаче сигналов с MSS-системой, использующие MGW-шлюз в качестве шлюза передачи сигналов.
Интерфейс передачи сигналов между MSS-системой и MGW-шлюзом представляет собой Ме-интерфейс. Он имеет две основные функции передачи сигналов, такие как Н.248 и SIGTRAN. В Truphone, Ме-интерфейс спроектирован таким образом, что обе MSS-системы имеют интерфейсы Н.248 и SIGTRAN со всеми шестью MGW-шлюзами, соединенными через основную магистральную линию связи. Н.248 переносится посредством Протокола передачи сигналов управления потоком данных (SCTP-протокола), который обеспечивает соединение с "множественной адресацией" между MSS-системой и MGW-шлюзом. Эта 'множественная адресация' обеспечивает два отдельных пути посредством использования двух IP-адресов в двух IP-подсетях на каждом конце соединения. Она используется для того, чтобы обеспечить эластичность на Ме-интерфейсе, и переносится посредством IP-протокола. Между MSS-системой и MGW-шлюзом будут созданы SIGTRAN-ассоциации для ΝΑΟ, ΝΑ1 и ΙΝΟ для цели TDM-межсоединения. Будет иметься две SCTP-ассоциации для каждого набора линий связи по передаче сигналов IP-протокола с MSS-системой, действующий в качестве сервера, и MGW-шлюзом, действующим в качестве клиента.
Nc-интерфейс представляет собой интерфейс между MSS-элементами. Он работает на протоколе SIP-I и BICC, и он основан на подсистеме управления. Никакая плоскость пользователя не вовлечена в этот интерфейс. По Nc-интерфейсу между MSS-системами выполняется передача сигналов управления вызовами на межсетевой основе. Альтернативный протокол управления вызовом в сети, основанной на IP-протоколе, который может быть использован в MSS-системе NSN, представляет собой Протокол инициирования сеанса связи с инкапсулированннной ISUP-подсистемой (протокол SIP-I). Это предоставляет подобную транку возможность передачи сигналов, аналогичную той, что предусмотрена в BICC. В MSS-системе, протокол SIP-I используется в качестве способа создания туннелей для сообщений ISUP-подсистемы.
Интерфейс плоскости пользователя между MGW-шлюзами представляет собой Nb-интерфейс. Все MGW-шлюзы в региональных центрах обработки данных соединены посредством IP-интерфейсов через основную магистральную линию связи RTP-протоколом, который используется для передачи данных в плоскости пользователя. Nb-интерфейс имеет отношение только к информации в плоскости пользователя между MGW-шлюзами и не имеет никакой прикрепленной к нему подсистемы управления.
Сеть SS7 (Системы сигнализации по общему каналу №7) снабжена Пунктами передачи по IP-протоколу, которые представляют собой узлы, ответственные за функции шлюза передачи сигналов и реализацию иерархической и централизованной маршрутизации для того, чтобы предоставить полные решения по передаче сигналов для МТР2 и МТР3. STP-пункты (Пункты передачи сигналов) имеют полностью резервированное решение со сдвоенно-узловой полностью ячеистой конфигурацией вплоть до сетевых элементов, для того, чтобы обеспечить преодоление отказов. Плоскость сети, используемая для SIGTRAN, осуществляет связь между каждой MSS-системой и всеми STP-пунктами в NAO.
Линии связи по протоколу SIGTRAN между парами MSS и STP основаны на SCTP-ассоциациях между звеньями передачи сигналов в MSS-системе и звеньями передачи сигналов на стороне STP-пункта. Между каждой MSS-системой и STP-пунктом в пределах пары STP-пунктов будут иметься две SCTP-ассоциации. Роль M3UA в MSS-системе будет "клиент", а роль STP-пункта будет "сервер".
MSS-системы соединены с парами STP-пунктов, расположенными в глобальных центрах обработки данных. Передача сигналов между MSS-системой и STP-пунктом основывается на протоколе SIGTRAN, использующем IP-сеть (сеть по протоколу межсетевого взаимодействия) CNO-оператора. MSS-система не имеет физической возможности соединения для прямой передачи сигналов с элементами сервисной платформы. Для того чтобы MSS-узлы поддерживали связь с элементами сервисной платформы и наоборот, будет, главным образом, использоваться SIGTRAN-интерфейс от MSS-системы к парам STP-пунктов. Маршрут передачи сигналов между MSS-системой и STP-пунктом представляет собой функциональную возможность Уровня 3 интерфейса передачи сигналов между ними. Маршрут передачи сигналов между MSS-системой и STP-пунктом может оставаться основной линией для маршрута передачи сигналов между MSS-системой и элементами сервисной платформы. Конфигурация маршрута передачи сигналов между MSS-системой и STP-пунктом может быть аналогична конфигурации маршрута передачи сигналов любого внутреннего сетевого элемента.
Сигнализатор (CS) начисления платы представляет собой платформу для реализации SCP-функций (Подсистемы управления обслуживанием) - в этом варианте воплощения изобретения она основывается на Сервере телекоммуникационных приложений (TAS-сервере) Opencloud Rhino и используется для того, чтобы реализовать функции IN-SCP (внутренние SCP-функции). CS используется для того, чтобы реализовывать сервисы CNO-оператора, такие как Интеллектуальный набор номера и Интеллектуальный CLI-сервис (сервис Идентификации линии вызывающего абонента), также как и интеллектуальные функции маршрутизации вызова. Интерфейс с базовой сетью представляет собой 3GPP САР и с OCS использует диаметр и HTTP-протокол (Протокола для передачи гипертекста). Профили абонентов хранятся в базе данных OCS и извлекаются по мере необходимости во время установления соединения.
TAS-сервер Rhino имеет SIP/ICS-интерфейс с базовой сетью, используемый для поддержания функций обратного вызова USSD. Стратегия преодоления отказа, развернутая CNO-оператором, аналогична стратегии, используемой для MSS-систем с полностью ячеистой межузловой конфигурацией без единственной точки отказа. В одном приводимом в качестве примера варианте компоновки, CNO-оператор использует протокол САР2 для завершения и речевых вызовов TSANned и протокол SIP/ISC для цели установления соединения для сервиса обратного вызова USSD.
IVR внешнего партнера будет напрямую соединяться с MSS-системой, используя SIP-протокол, и одновременно соединяться напрямую с MGW-шлюзом, используя RTP-протокол (Протокол транспортного уровня в реальном масштабе времени).
MSS-системы соединены с HLR-регистрами, расположенными в глобальных центрах обработки данных, через STP-пункты (Пункты передачи сигналов). Каждый узел будет иметь SIGTRAN-ассоциации с парой сетевых STP-пунктов. Каждый HLR-регистр имеет код пункта передачи сигналов и глобальный заголовок для того, чтобы обеспечивать правильную маршрутизацию. HLR-регистр будет иметь SIGTRAN-стек передачи сигналов, и каждый HLR-регистр будет физически соединен с парами STP-пунктов в сети. MSS-система CNO-оператора осуществляет маршрутизацию передачи сигналов по направлению к HLR-регистру через этот STP-пункт. Для того чтобы обеспечить возможность полностью ячеистого соединения, эти STP-пункты будут работать как совместно нагруженные части для любого сообщения, отправленного в HLR-регистр). Межузловые ячеистые линии связи могут обезопасить в случае, если имеет место нарушение связи в некотором конкретном узле сети, и могут перенаправить передачу сигналов на второй узел и сохранить сервис в рабочем состоянии.
SMSC-центры (Центры Службы коротких сообщений) соединены с MSS-системой через пары STP-пунктов. Маршрутизация передачи сигналов, используемая между MSS-системой и SMSC-центром представляет собой маршрутизацию в SCCP-подсистеме, основанной на коде пункта и номере подсистемы. Для преодоления отказа вновь может быть обеспечена полностью ячеистого соединения.
Передача сигналов от MSS системы к MFS-сервисам обеспечивается через ITP. Многофункциональные сервисы (MFS) представляют собой сетевой элемент, ответственный за 3 сервиса: шлюз MAP SRI; MAP PRN Fix; и MNP DIPS (DIPS Переносимости номеров мобильной связи). Переносимость номеров мобильной связи у CNO-операторов может быть предусмотрена в каждом глобальном центре обработки данных.
В различных географических областях могут быть предусмотрены различные назначаемые по умолчанию несущие для передачи сигналов. В качестве протокола передачи сигналов для межсоединения может быть использован SIGTRAN. Для того чтобы повысить эластичность, CNO-оператор может иметь полностью ячеистые линии (SS7) связи по частным одноранговым IP-сетям. Эти линии связи могут быть созданы посредством М2РА по SCTP-протоколу (Протоколу передачи сигналов управления потоком данных), и способ маршрутизации представлял бы собой GT как у вызывающей, так и у вызываемой стороны. Несущая передачи сигналов может быть ответственна за преобразования из формата ANSI (Американского института национальных стандартов) в формат ITU (Международного союза электросвязи) и из формата ITU в формат ANSI для соответствующих ITP по направлению к CNO-оператору/от него.
Примером сервиса, предоставляемого в такой архитектуре, является переносимость номеров мобильной связи (MNP-переносимость). Переносимость номеров мобильной связи между сетевыми операторами известна, но различные страны имеют различные регулятивные подходы, и различные последовательности операций. Настоящая архитектура подходит для структурированного многоуровневого подхода с общим основным процессом и региональной адаптацией. Это делает возможной более высокую гибкость и эффективное многократное использование кода. Как обсуждается ниже, эта базовая модель применима к другим сервисам, которые имеют основные элементы, общие для всех географических областей, но специфические элементы, которые являются зависящими от конкретной страны.
На фиг. 19 показана многоуровневая архитектура сервиса, которая позволяет обработке MNP-переносимости быть изолированной, применяя при этом, там, где это возможно, общие процессы. Вопросы комплексной интеграции, специфические для локальных географических областей, могут быть изолированы для этих географических областей (и таким образом, выполняться, например, в соответствующем региональном или локальном узле, а не в центральном узле).
Первый уровень (Фасадный уровень) представляет собой вывеску сервиса или API-интерфейс (Интерфейс прикладной программы), который открывает функциональные возможности MNP-переносимости другим системам и процессам. Этот уровень изолирует функциональные возможности и сложности MNP-переносимости внутри 'системы MNP-переносимости'. Это в свою очередь обеспечивает то, что другие системы могут обращаться с MNP-переносимостью просто и последовательным образом, имея только необходимость понимать, что существует некоторая система, которая будет иметь дело со всей обработкой данных, относящейся к MNP-переносимости, независимо от того, какой подход может требоваться для некоторой данной страны. Система MNP-переносимости не должна иметь никакого знания о том, какие внешние системы или процессы могут использовать ее сервисы, коль скоро запрос является санкционированным и правильно сформированным, системы MNP-переносимости попытаются его обработать. Благодаря достижению изоляции системы MNP-переносимости обеспечивается то, что эта система является многократно используемой в любом наборе систем, потребляющих сервисы и функциональные возможности MNP-переносимости.
Второй уровень (Уровень обобщения) содержит общие или обобщенные функциональные возможности, функциональные возможности, которые являются общими для всех подходов MNP-переносимости. Для уменьшения сложности и эксплуатационных накладных расходов эти общие функциональные возможности должны быть осуществлены только однажды. Этот вариант осуществления следует рассматривать как 'центральный'. Этот уровень взаимодействует с Фасадным уровнем (на самом деле, он может осуществлять этот уровень), и Уровень реализации, описываемый ниже. Уровень обобщения интегрируется с Уровнем реализации посредством единой интеграционной структуры. Притом что Уровень обобщения обслуживает в некотором смысле все функциональные возможности, где некоторая конкретная область функциональных возможностей варьируется в зависимости от обслуживания, специфического по подходу или специфического по стране, в таком случае функциональные возможности, представленные на этом уровне, являются просто оберткой для функциональных возможностей, достигаемых на последующих уровнях, некоторый стандартный набор информации используется для представления функции, но для обработки она передается дальше на другие уровни. Например: общее управление состоянием (например, то, где в процессе выполнения Порта находится некоторый конкретный запрос) является общим для всех подходов к MNP-переносимости (хотя сами значения состояния могут отличаться). Им, следовательно, занимались бы на Уровне обобщения.
Третий уровень (Уровень реализации) содержит функциональные возможности, которые являются специфическими для небольшого количества обобщенных подходов к MNP-переносимости. Каждый обобщенный подход имеет свой собственный 'компонент', осуществляющий функциональные возможности, специфические для этого подхода. Уровень реализации интегрируется с Уровнем обобщения посредством единой интерфейсной структуры. Каждый компонент, специфический для подхода, на Уровне реализации интегрируется с Уровнем соединения (обсуждаемым ниже) посредством интерфейсной структуры, специфической для этого компонента. Компоненты в пределах Уровня реализации не понимают специфику того, как любая данная страна, которая использует общий подход, связанный с этим компонентом, осуществляет этот подход. Возможно, что для некоторых подходов не нужно достигать никакой специфических обработки данных или функциональных возможностей в дополнение к этим обработке и функциональным возможностям на Уровнях обобщении и соединения. Например: в Великобритании MNP-переносимость осуществляется с использованием 'Подхода с Кодом полномочия', при котором между сетевыми операторами передают некоторый санкционирующий код. Этот 'кодовый подход' также используется в небольшом количестве других стран по всему миру. Предпочтительно, чтобы на Уровне реализации существовал некоторый компонент, который обеспечивает функциональные возможности и обработку данных, требующиеся для осуществления 'подхода с кодом полномочия' к обработке данных при MNP-переносимости. Этот компонент использовался бы повсюду, где страна осуществляет MNP-переносимость в стиле 'кодового подхода'.
Четвертый уровень (Уровень соединения) содержит функциональные возможности, которые являются специфическими для страны, для которой должна быть выполнена обработка данных для MNP-переносимости. Это включает в себя интеграцию с какими бы то ни было внешними сервисами, и/или процессами, требующимися в этой стране, в форматах данных, требующихся для этой страны. Уровень соединения интегрируется с Уровнем обобщения через интерфейс, специфический для подхода к MNP переносимости, который осуществляет эта страна. Компоненты в пределах Уровня соединения являются полностью специфическими для страны, которую они обслуживают. Например: вызов сервиса в Великобритании управлял бы обработкой интерфейса и содержимым информации, специфическими для Великобритании. Этот вызов сервиса в Великобритании использовался бы компонентом, имеющим 'подход с кодом полномочия' (потому что Великобритания осуществляет MNP-переносимость в стиле 'подхода с кодом полномочия'), и достигал бы интеграции с "расчетной палатой" (центральным пунктом связи для обработки MNP-переносимости в Великобритании).
Эта технология будет теперь описана более подробно со ссылкой на конкретные модель сообщения и последовательность операций.
Иерархическая модель сообщения показана на фиг. 20. Эта модель сообщения (Структура MNP-переносимости) определяет иерархическое дерево канонических моделей сообщения. Это обеспечивает полиморфный подход к динамическому отправлению сообщений провайдера сервиса, специфического для страны, следующим образом:
Исходные типы (101) определены на Фасадном уровне. Это определяет абстрактный и "чистый" уровень Типов для поддержки Фасадного уровня. Основная модель (102) сообщения унаследована от Исходного типа. Интерфейс, определенный на Уровне обобщения будет использовать этот тип. Основная модель сообщения предоставляет знание (103) о доменных моделях используемым на Уровне обобщения.
Знание (104) о каждом специфическом бизнес-домене на Уровне реализации наследует знание, определенное в Обобщении. Это наследование предоставляет путь (105) передачи знания, так что мы поддерживаем как разделение вопросов знания доменов, так и избежание дублирования общих вопросов. Специфические бизнес-домены на Уровне реализации пребывают в полиморфизме областей знания-эти бизнес-домены на Уровне реализации слабо связанны друг с другом и могут обрабатываться независимо (в качестве одного конкретного примера показан Домен Кода полномочия порта (РАС-Домен) - однако, они все наследуют знание от Уровня обобщения. На Уровне реализации может иметься больше чем один уровень (108) наследования.
Домены (110), специфические для страны, находятся на Уровне соединения, и наследуют знание из бизнес-доменов с Уровня реализации. Знание в доменах, специфических для страны, находится в соответствующем каноническом формате. Имеется некоторый интерфейс, находящийся на этом Уровне соединения, обеспечивающий преобразование между фактическим форматом данных для MNO-оператора страны и каноническим форматом для страны. Частное знание может, таким образом, быть защищено и отсоединено от внешнего мира.
На фиг. 21 показана обобщенная последовательность операций для MNP-переносимости. Фасадный интерфейс предоставляет "чистый" и унифицированный интерфейс (201) для поддержания запросов MNP-переносимости от многоканальных клиентов. Доступ в сеть "Интернет" может осуществляться через web-браузер (202), клиента с широкими возможностями, использующего настольное приложение (203), мобильный доступ через устройства (204) мобильной связи или через партнеров (205) канала. Фасадный уровень распространит (206) сообщения с запросами соответствующим интерфейсам, определенным для Общего Шлюза на Уровне обобщения. Общий шлюз определяет общий интерфейс для приема иерархического дерева полезных данных сообщения в различающихся форматах. Использование интерфейса Общего шлюза на Фасадном уровне минимизирует воздействие внутренних изменений на Фасадных клиентов. Это может быть продемонстрировано в нижеследующих двух примерах: 1) изменение интерфейса или последовательности операций существующего MNO-оператора (Оператора сети мобильной связи) Страны не имело бы никакого влияния на инициирование работы Фасадного уровня клиентами; и 2) добавление нового MNO-оператора Страны не будет влиять на существующий у клиента код, но даст клиенту новую возможность представлять дополнительные запросы.
Обобщенный сервис (209) MNP-переносимости использует Знание [210] реализации для того, чтобы обрабатывать запросы, представленные через Общий шлюз [208]. Знание реализации "знает" следующий уровень бизнес-домена (но не подробности его осуществления), и, таким образом, может динамически отправлять запросы следующему домену реализации. Уровень реализации содержит от 1 до n этапов последовательностей операций реализации между Доменами реализации. Каждый уровень реализации содержит специфические бизнес-домены, каждый из них имеет свое собственное доменное знание, которое содержит доменные модели и предоставлять соответствующий бизнес-процесс для выполнения доменной логики. Как указывалось ранее, примером домена является РАС-домен (домен Кода полномочия порта). Каждый Домен на Уровне реализации имеет свое Знание реализации и может использовать его для того, чтобы динамически отправлять последовательность реализации на следующий этап, который представляет собой либо другой уровень специфического домена или Соединитель на Уровне соединения.
Уровень соединения содержит множество Соединителей, каждый из которых предоставляет подробности осуществления для того, чтобы соединиться с некоторым конкретным MNO-оператором Страны. Это соединение может быть двунаправленным. Поток (данных) от специфического домена к Соединителю мог бы также быть двунаправленным, в зависимости от последовательности операций, специфической для этого домена. Каждый Соединитель содержит некоторое Преобразование, которое преобразует частную каноническая модель данных для страны в фактическую модель данных для MNO-оператора Страны. Следовательно, внутреннее частное знание защищено и отсоединено от внешнего мира. Каждый Соединитель содержит Адаптер для обработки подробностей осуществления соединения. Существует отношение наследования/расширения в горизонтальном направлении, таким образом, горизонтальное направление предоставляет функции: от общих до более специфических. Горизонтальное направление предоставляет всю последовательность функций для реализации функции MNP-переносимости, специфической для Страны, от начала до конца. Домены реализации вертикально разъединены друг с другом, и, таким образом, могут быть подключаемыми с минимальным влиянием на всю структуру. Домены имеют полиморфизм в вертикальном направлении. Соединители Стран могут быть гибко подключаемыми с минимальным влиянием на более высокие уровни. Соединение между Доменами на Уровне реализации с Соединителями на Уровне соединения с MNO-операторами Страны могло бы быть двунаправленным.
На фиг. 22 показано то, как этот подход осуществляет наследование и многократное использование. Структура, основанная на четырех уровнях, предлагает большую возможность многократного использования при небольшой зависимости знаний, так что осуществление или изменение переносимости номеров любого MNO-оператора, специфического для Страны, могут быть подключены или отключены наиболее гибким образом с минимальным влиянием на потребителей этой структуры.
Горизонтальное направление этой структуры предлагает наследование и расширение сервисов. Может быть определено некоторое иерархическое дерево канонических моделей сообщения для горизонтальных сервисных контрактов. "Чистый", простой общий интерфейс был определен для Фасадного уровня, который позволяет потокам данных сообщения динамически отправляться и "обогащаться" в горизонтальном направлении. Бизнес-логика сервиса продолжается и расширяется в горизонтальном направлении для того, чтобы обрабатывать эти сообщений. Типичным примером является горизонтальная последовательность операций сервиса для осуществления Подхода с Кодом полномочия для британского MNO-оператора. Запросы MNP-переносимости динамически отправляются и текут в PAC-Домен (Домен Кода полномочия порта) MNP-переносимости, который осуществляет логику Подхода с Кодом полномочия, и затем передаются Соединителю сервиса Великобритании, каковой Соединитель преобразует каноническую модель к модели данных MNO-оператора Великобритании и обрабатывает подробности транспортировки низкого уровня для того, чтобы выполнить отправку почтового сообщения по HTTP-протоколу (Протоколу для передачи гипертекста) этому MNO - оператору Великобритании. После этого, для того, чтобы внедрить MNO-оператора другой Страны, основывающейся на Подходе с Кодом полномочия, например, Индии, необходимо только подключить Соединитель, специфический для Страны, для того, чтобы обрабатывать подробности преобразования и транспортировки. Обновление и модификация Соединителя Великобритании не имели бы никакого влияния на Соединителя MNO - оператора Индии, и наоборот. Это обеспечивает горизонтальный полиморфизм.
В вертикальном направлении, эта структура поддерживает максимально многократное использование компонентов общего класса. Общие функциональные возможности между Доменами реализации или между Соединителем Сервиса для Графства могут быть абстрактно представлены как шаблон. Может быть использован подход проектирования объектно-ориентированного шаблона. Шаблон, используемый в вертикальном направлении, может предложить Способность Назначения Главной ответственности для общих функциональных возможностей. Типичным примером является Управление сеансом связи, которое мы осуществили для британского Соединителя. Вместо открывания/закрывания сеанса связи в каждом соединении, защищенный сеанс связи по HTTP-протоколу кэшируется и сохраняется для множественных Почтовых сообщений по HTTP-протоколу для того, чтобы улучшить рабочие характеристики системной интеграции между частной системой и внешними системами. Проект Шаблона управления сеансом связи предлагает в вертикальном направлении прозрачность всем Соединителям MNO-операторов Стран, используя в своей основе HTTP-протокол, например, SOAP/HTTP (Простой протокол доступа к объектам/Протоколу для передачи гипертекста), обыкновенный HTTP-протокол или REST (Протокол передачи репрезентативного состояния) и так далее. Это обеспечивает полиморфизм в вертикальном направлении.
Другая модель сервиса, использующая тот же самый общий подход, предназначена для Сервисов телефонного справочника и номеров. Имеется аналогичная проблема для решения, в которой запрашиваемые номера (MSISDN (международные номера мобильных станций цифровой сети с интегрированным обслуживанием)) из множественных стран, которые имеют несопоставимые подходы к Сервисам телефонного справочника и номеров. Это позволяет запрашивающему объекту быть неосведомленным о специфике регуляторного подхода каждой страны к Сервисам телефонного справочника и номеров. Показанный выше подход позволяет запрашивающему объекту быть неосведомленным о специфике регуляторного подхода каждой страны к Сервисам телефонного справочника и номеров.
Каждая страна имеет свой собственный регулятивный подход для Сервисов телефонного справочника и номеров, содержащий правила в этой стране в отношении того, как следует искать MSISDN, и местный закон, относящийся к праву индивидуумов представлять или не представлять свои номера в сервисах телефонного справочника или иметь свои номера полностью или частично скрытыми на счетах и на других выходных документах. Как и для MNP-переносимости, хотя обобщенный объем Сервисов телефонного справочника и номеров по странам является в значительной степени общим, конкретное осуществление варьируется для каждой страны.
Например:
- В Нидерландах потребитель может попросить, чтобы из MSISDN-номер был 
там, где он появляется на счетах или других записях других потребителей. Это 
принимает форму замены знаком "решетка" последних трех цифр MSISDN-номера на таком выходном документе.
- В Германии некоторый MSISDN-номер никогда не может быть показан на счете или другом выходном документе.
- В Австралии потребитель может выбрать давать согласие или выбрать не давать согласие (значение по умолчанию "дать согласие") в отношении того, чтобы их номера были доступны для организаций сервисов телефонных справочников.
- В Польше регулятор должен быть проинформированным о проданном MSISDN-номере немедленно по его активации.
Такой разброс можно обрабатывать без сложной центральной обработки, используя тот же самый архитектурный подход, что был описан выше для MNP-переносимости. Логика сервиса, очевидно, будет другой, но будет выполнять те же самые принципы. От физического взаимодействия с регуляторами и/или операторами сервисов телефонных справочников логическая обработка данных абстрагируется, позволяя ему варьироваться с каждой страной. Общие функции группируются в домены, которые могут варьироваться в своем осуществлении в соответствии с потребностями каждой конкретной реализации-эти реализации могут иметь n-уровневую структуру, зависящую от конкретной сложности реализации. Например:
- логика выбора дачи согласия/выбора недачи согласия для сервисов телефонных справочников может быть в значительной степени общей даже при том, что фактическая интеграция с регуляторами является специфической для страны;
- подходы защиты номеров сильно варьируются по странам, но относятся к трем или четырем обобщенным подходам (например, защита специальных номеров, защита вашего номера на выходных документах других лиц, защита номеров на собственная выходных документах потребителей и так далее),
Другой вопрос, которой можно масштабируемым образом решать посредством этой модели архитектуры, представляет собой классификацию номеров. Номера имеют ассоциативно связанные с ними данные и метаданные. Данные сообщают нам информацию о конкретных номерах. Метаданные дают нам информацию о самих этих данных и дают нам возможность делать много вещей; например, когда проводится продажа, мы можем использовать метаданные для динамического построения UI (пользовательского интерфейса) для того, чтобы задать уместные вопросы о виде номера, который мы хотим купить. Ниже описывается система для определения иерархических метаданных, ассоциативно связанных с классами номеров.
Проблема для построения системы управления номерами для глобального оператора сети мобильной связи заключается в том, что не все элементы данных, ассоциативно связанные с номером будут релевантны во всех случаях, релевантность может измениться со временем, и при расширении в новые страны могут быть необходимы новые элементы. Традиционная табличная классификация номера с метаданными показана на фиг. 23. Это создает трудность в том случае, если необходимы новые поля.
На фиг. 24 показана более хорошая модель, в которой используется схема, а не таблица. Теперь имеется возможность добавлять новый элемент данных, не изменяя схему. Для того, чтобы добавить новый элемент, мы;
- добавляем новую строку в таблицу Категорий, например, 'Страна'
- добавляем все ее возможные значения в таблицу CategoryValue (ЗначениеКатегории), например, 'Афганистан', 'Албания', 'Алжир' …
- добавляем связующую запись в таблицу NumberCategory (КатегорияНомера) для того, чтобы ассоциативно связать одно или более значение CategoryValue с некоторым конкретным номером, например, 'Страна = Алжир и 'Использование = Первичное'
Дополнительные правила, не присутствующие в этой модели, могут быть представлены в качестве метаданных. Примеры представляют собой следующее:
- Если номер представляет собой номер в Соединенных штатах Америки, то также должен быть указан штат
- Если номер представляет собой номер в Соединенных штатах Америки, то должна быть определена категория использования
- Если номер представляет собой алжирский номер, то должна быть указана Специальная категория
- В будущем мы можем изменить категорию использования так, чтобы она применялась только к номерам из 'Алабамы' и 'Вирджинии'
Это может быть решено путем добавления таблицы зависимостей. Она определяет иерархию взаимозависимых записей значений CategoryValue для соблюдения этих правил. Приводимая в качестве примера конфигурация представляет собой:
Необходимость интерпретировать таблицу зависимостей имеется в трех сценариях;
- Когда мы загружаем новые номера в систему, каждый номер должен быть классифицирован соответствующим образом;
- Когда мы покупаем номер, необходимо задать вопросы о виде номера, которым мы интересуемся (это - UI (пользовательский интерфейс) динамической продажи);
- Если правила классификация изменяются, и нам необходимо повторно проанализировать все номера для того, чтобы увидеть то, о каких из них мы должны предоставить дополнительную информацию.
Таблица зависимостей интерпретируется при категоризации номера или диапазона номеров. Только первая строка в этой таблице не содержит значение 'зависит от'. Это означает, что первая строка применима ко всем номерам. Эта запись также ссылается на категорию стран, что означает то, что все номера должны определить страну, к которой они принадлежат. Если мы динамически построили UI (пользовательский интерфейс) для того, чтобы выбрать тип приобретаемого номера; то имело бы своим результатом окно с единственным списком, в котором отображаются все связанные с этим значения CategoryValue (ЗначенияКатегории) (то есть, все страны мира). Одна из них должна быть выбрана. Как только выбор сделан, таблица зависимостей снова анализируется в свете принятого решения. Если из списка выбраны США, то вступают в действие строки 1 и 4 из таблицы зависимостей, поскольку они 'зависят' от значения категории, составляющего 250 (Страна = 'США'). Строка 1 говорит о том, что должно быть отображено окно списка для 52 значений Категории Штаты США. Строка 4 аналогичным образом имеет своим результатом отображаемое окно списка, из которого мы можем выбрать Использование; 'Первичное' или 'Вторичное'. Если мы выбираем 'Калифорнию' для Штата, то требуется дополнительная классификация для категории Специальная; Золотая, Серебряная или Стандартная. Можно также заметить, что категория Специальная также применяется к 'алжирским' номерам (строка (2) таблицы зависимостей). Это проиллюстрировано на фиг. 25.
Эта система является чрезвычайно гибкой. Можно, например, видеть, что тривиально заменить строку таблицы зависимостей для того, чтобы применить категорию использования только к некоторым штатам США, а не ко всем штатам США. Эта описанная логика типичным образом будет инкапсулирована в программном компоненте многократного использования и встроена для различных случаев использования. Также имелась бы возможность динамически обновлять таблицу зависимостей в ответ на изменения в пуле номеров, например, удаляя ссылку на значение категории, представляющее собой 'Нью-Йорк в случае, когда никаких нью-йоркских номеров не имеется.
Как было указано выше, этот архитектурный подход, и подход к предоставлению сервисов, является чрезвычайно действенным. Он делает возможной конфигурацию сети мобильной связи для оператора сети во множественных странах, осуществляя общие элементы в одном или более центральных узлах, распределяя при этом элементы, в которых критически важны время и объем, по региональным узлам. Это поддерживает конфигурирование телекоммуникационного комплекта для предоставления сервисов мобильной связи потребителям во множественных регионах, благодаря выделению общих элементов в некоторое центральное ядро функциональных возможностей и реализации структурных адаптеров для того, чтобы справляться с региональной вариацией. В случае, при котором региональная вариация подлежит осуществлению в региональном узле, необходимые функциональные возможности могут быть распределены этому узлу. Некоторые региональные узлы могут также предоставлять копии центральных узлов, и могут вступать в дело для того, чтобы обеспечить резервирование.
Этот подход может быть использован для того, чтобы избежать предшествующих географических ограничений, сохраняя при этом локализацию для абонента. Например, преобразование исходного IP-пакета (пакета по протоколу межсетевого взаимодействия) может быть предусмотрено таким образом, чтобы казалось, что потребитель является местным для некоторой географической области, скажем Германии, когда их пакетный трафик направляется из Амстердама. Манипулирование APN-именем (именем точки доступа) может иметь место первоначально на основе сравнения IMSI-номера (Международного идентификационного номера абонента мобильной связи) абонента и комбинации MNC (Кода сети подвижной связи)/МСС (Кода страны в системе мобильной связи), предоставляемой SGSN-узлом (Обслуживающим узлом поддержки GPRS (Общего сервиса пакетной радиопередачи)).
Магистральная линия связи по IP-протоколу может выполнить отображение на "национальный" IP-адрес. Для того, чтобы абоненты следовали практике предпочитаемой ими страны, персональные настройки потребителя, в таком случае, могли бы использоваться таким образом, чтобы подменять собой информацию о месте расположения.
Как было описано выше, может быть предоставлено локализованное APN-имя, что делает возможным пакетный трафик к наиболее эффективному маршруту к ближайшему GGSN-узлу (Шлюзовому узлу поддержки GPRS (Общего сервиса пакетной радиопередачи)) или шлюзу пакетной передачи. Это поддерживает оптимизацию маршрутизации. Например, сеть и пользовательское оборудование могут динамически конфигурироваться для более хорошей маршрутизации сервисов голосовой связи или сервисов передачи данных и для того, чтобы устанавливать предпочтения в отношении соединения для пользовательского оборудования для того, чтобы сделать возможным быстрое подсоединение. Аналогичным образом, маршрутизация голосовой информации и данных для некоторого данного потребителя основывается на исходных местах расположения пункта назначения, относящихся к пункту назначения транзакции, и располагаемых ресурсов маршрутизации по частично распределенной сети мобильных телекоммуникаций таким образом, чтобы передача сигналов была сопряжена с центром, чтобы сделать возможным управление выставлением счетов и вызовами. Изменение режима маршрутизации при связи с некоторым предпочтительным путем доставки может основываться на технологии (Wi-Fi/стандарте GSM (Глобальной системы мобильной связи)/стандарте LTE (Долгосрочной эволюции)) в однонаправленном канале и месте расположения исходного пункта, пункта назначения. Может также быть выбрана эффективная маршрутизация, делающая возможным отправление SMS-сообщений и голосовых вызовов в распределенной сети, не требующая при этом разглашения мультимедийных данных и SMS-сообщений через сети третьих лиц.
Могут быть предоставлены множественные номера мобильного телефона из множественных стран или из одной страны, которые (номера) продуманно отображаются на сервисы таким образом, чтобы все сервисы были доступны для всех номеров, модифицируемых в соответствии с местом расположения источника и номером и/или местом расположения пункта назначения.
Общее сервисы могут быть предоставлены по различным международным идентификаторам. Например, единый счет, сервис потребителя и голосовая почта могут быть предоставлены абоненту, несмотря на то, что этот абонент имеет множественные международные идентификаторы. Аналогичным образом, законный перехват и экстренные службы могут быть предоставлены по множественным международным идентификаторам. Особая польза от использования этого подхода с системой для снабжения абонента множественными идентификаторами, как в WO 2011/036484, заключается в том, что проще согласовать между собой эти идентификационные данные абонента для предоставления общего обслуживания. Можно сделать выбор в пользу пользовательского опыта, позволяя потребителю набирать телефонные номера пунктов назначения его родной страны в национальном формате, даже, например, при роуминге, и идентификация и ограничение линии вызывающего абонента могут быть обеспечены единообразно для абонента по множественным географическим областям, в той мере, в которой это разрешается законом.
Эта модель имеет дополнительные последствия для управления сетью связи. Например, по всей сети могут быть распределены активные сетевые зонды таким образом, чтобы функционировать как один логический узел, что позволяет системе зондов в целом иметь гарантированное качество. Сетевые зонды могут иметь каждый свой собственный идентификатор, и могут соответствующим образом поддерживать связь, но на высоком уровне они будут взаимодействовать с другими элементами и сервисами как единый логический узел.
Как было описано выше, может быть использована модель сервиса, использующая иерархическое описание сервиса с осуществленной в центре общей моделью и регионально осуществленной региональной вариацией. Для переносимости номеров мобильной связи, это может включать в себя перенос номеров одновременно во множественных странах, несмотря на наличие различных моделей переноса в этих странах. Это предусматривает интеграцию с множественными международными моделями MNP-переносимости, использующую стандартизированную структуру, такую что на каждом уровне протокола должно адаптироваться только наименьшее количество элементов. Для сервисов телефонного справочника и номеров, это может включать в себя предоставление номера, действующего во многих странах, и сервис отображения короткого кода, такой что общеизвестные номера, такие как сервисы Телефонных справочников (в Великобритания-118, в США-555 и так далее) и платные сервисы, разрешаются с приведением к локальной схеме нумерации в каждой стране или системе номеров родной страны, в соответствии с правилами, основанным на родной стране, месте расположения и предыдущей истории. Законы о нумерации могут быть отображены в многонациональном масштабе, так, чтобы были показаны правильно в каждой локальной юрисдикции в соответствии с локальной практикой.
Этот подход также поддерживает управление номерами путем резервирования предпочитаемых номеров по множественным географическим областям. Это может включать в себя, например, резервирование схожих номеров во множественных странах после того, как потребитель купил номер в одной стране.
С использованием этой модели возможна и другая независящая от страны компоновка сервисов. Например, имеется возможность позволить группе индивидуумов, чтобы они могли совместно использовать общий пул минут независимо от географических границ, будучи при этом, если требуется, юридически связанными контрактом с отличающимися валютами и получая счета на оплату в этих валютах.
Изобретение относится к области вычислительной телекоммуникационной техники. Технический результат заключается в исключении задержек соединения абонентов сервисов сотовых телекоммуникаций. Технический результат достигается за счет получения в системе передачи данных запроса на перенос номера мобильной связи для переноса номера, связанного с абонентом, от первого оператора сети мобильной связи ко второму оператору сети мобильной связи; предоставления в системе передачи данных множества процессов адаптации оператора сети мобильной связи страны для переносимости номера мобильной связи, причем каждый процесс адаптации оператора сети мобильной связи страны предоставляется от соответствующего одного из множества региональных узлов в системе передачи данных, причем каждый региональный узел охватывает соответствующую различную группу одного или нескольких операторов сети мобильной связи страны; и предоставления переносимости номера мобильной связи абоненту в системе передачи данных путем реализации общего основного процесса и соответствующего одного из множества процессов адаптации операторов сети мобильной связи страны. 7 з.п. ф-лы, 28 ил., 1 табл.
1. Способ обеспечения переносимости номера мобильной связи абонентам в системе передачи данных для множества операторов сети мобильной связи страны, содержащий:
получение в системе передачи данных запроса на перенос номера мобильной связи для переноса номера, связанного с абонентом, от первого оператора сети мобильной связи ко второму оператору сети мобильной связи;
предоставление в системе передачи данных общего основного процесса для переносимости номера мобильной связи из центрального узла, охватывающего все множество операторов сети мобильной связи страны;
предоставление в системе передачи данных множества процессов адаптации оператора сети мобильной связи страны для переносимости номера мобильной связи, причем каждый процесс адаптации оператора сети мобильной связи страны предоставляется от соответствующего одного из множества региональных узлов в системе передачи данных, причем каждый региональный узел охватывает соответствующую различную группу одного или нескольких операторов сети мобильной связи страны; и
предоставление переносимости номера мобильной связи абоненту в системе передачи данных путем реализации общего основного процесса и соответствующего одного из множества процессов адаптации операторов сети мобильной связи страны.
2. Способ по п. 1, в котором способ содержит предоставление в системе передачи данных соответствующих соединителей между каждым из региональных узлов и, по меньшей мере, одним оператором сети мобильной связи страны.
3. Способ по п. 2, в котором соединители включают в себя, по меньшей мере, один из множества различных протоколов, выбранных из: протокол для передачи гипертекста (HTTP), протокол простого обмена электронной почтой (SMTP), простой протокол доступа к объектам (SOAP) и протокол передачи репрезентативного состояния.
4. Способ по любому из предыдущих пунктов, в котором, по меньшей мере, один из региональных узлов обеспечивает процесс адаптации оператора сети мобильной связи страны для переносимости номера мобильной связи для множества стран.
5. Способ по любому из предыдущих пунктов, в котором, по меньшей мере, один из региональных узлов обеспечивает процесс адаптации оператора сети мобильной связи страны для переносимости номера мобильной связи для одной страны.
6. Способ по любому из предыдущих пунктов, в котором центральный узел содержит центральный интерфейс для приема запросов на перенос номера мобильной связи от клиентских приложений в сети мобильной связи.
7. Способ по любому из предыдущих пунктов, отличающийся тем, что способ содержит предоставление в системе передачи данных одного или более промежуточного процесса для переносимости номера мобильной связи, при этом, по меньшей мере, один промежуточный процесс для переносимости номера мобильной связи выполняет функции, которые являются общими для поднабора множества операторов сети мобильной связи страны.
8. Способ по п. 7, в котором, по меньшей мере, один промежуточный процесс взаимодействует с множеством процессов адаптации оператора сети мобильной связи страны, чтобы обеспечить переносимость номера мобильной связи, и в котором предоставление переносимости номера мобильной связи абоненту дополнительно содержит осуществление соответствующего одного из одного или более промежуточных процессов.
| US 6421438 B1, 16.06.2002 | |||
| Способ обработки целлюлозных материалов, с целью тонкого измельчения или переведения в коллоидальный раствор | 1923 |
|
SU2005A1 |
| Способ извлечения фосфора из фосфорсодержащих печных газов | 1980 |
|
SU981211A1 |
| СПОСОБ СОТОВОЙ СВЯЗИ | 2003 |
|
RU2227373C1 |
| ЦИФРОВАЯ ТРАНКИНГОВАЯ СЕТЬ СВЯЗИ, ПОДДЕРЖИВАЮЩАЯ РОУМИНГ, И СООТВЕТСТВУЮЩИЙ СПОСОБ ОБЕСПЕЧЕНИЯ РОУМИНГА | 2004 |
|
RU2345509C2 |
