×
20.10.2013
216.012.779a

СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ

Вид РИД

Изобретение

Юридическая информация Свернуть Развернуть
№ охранного документа
0002496278
Дата охранного документа
20.10.2013
Краткое описание РИД Свернуть Развернуть
Аннотация: Изобретение относится к области технологий сетевого доступа (NAT), a именно к способу, который позволяет функциональному компоненту, расположенному на первой платформе сетевого доступа, связываться с функциональным компонентом, расположенным на второй платформе сетевого доступа. Технический результат заключается в обеспечении возможности осуществить связь низкого уровня между двумя или несколькими платформами сетевого доступа. Для этого обеспечивают первую платформу, содержащую первый функциональный компонент, выполненный с возможностью обеспечения и/или запроса основанной на платформе функции ко второму функциональному компоненту, расположенному на второй платформе сетевого доступа, и/или от него. Затем устанавливают на первой платформе сетевое приложение межплатформенной связи, выполненное с возможностью управления сигнализацией между первым функциональным компонентом и вторым функциональным компонентом и разрешают контактирование приложения межплатформенной связи с первой функцией межплатформенного программного обеспечения, обеспеченной для доступа ко второму функциональному компоненту. При этом устанавливают путь связи между функциональными компонентами на разных платформах сетевого доступа через приложение межплатформенной связи и первую функцию межплатформенного программного обеспечения. 6 н. и 21 з.п. ф-лы, 14 ил.
Реферат Свернуть Развернуть

Область техники

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

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

Мобильные телефоны традиционно были устройствами, ориентированными на передачу речи со специально разработанными операционными системами, управляющими всеми задачами связи. Интерфейсы прикладного программирования (API) в этих устройствах не были сделаны доступными сторонним разработчикам. Как следствие, конечные пользователи зависели от производителей устройств для приложений.

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

A.Ghosh и др., “Open application environments in mobile devices: Focus on JME and Ericsson Mobile Platforms”, Ericsson Review № 2, Vol.82, 2005 г., стр.82-91 (ISSN: 0014-0171) описывают примерную открытую среду приложений для мобильных устройств. Эта открытая среда приложений основана на мобильной платформе с цифровым процессором основной полосы частот, поддерживающим беспроводные NAT, так называемые технологии радиодоступа (RAT), такие как система пакетной радиосвязи общего пользования (GPRS), усовершенствованные данные для развития GSM (EDGE) или широкополосный множественный доступ с кодовым разделением (WCDMA). Мобильная платформа является средой, которая включает в себя все необходимые интегральные схемы и программное обеспечение, необходимое для обеспечения служб беспроводного сетевого доступа и служб связи (например, для приложений передачи речи, данных или мультимедиа), а также интерфейсов для того, чтобы сделать эти службы доступными для приложений, находящихся на мобильной платформе.

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

Обычно мобильные платформы часто включают в себя оригинальные операционные системы (OS). Теперь, с появлением открытой среды приложений, платформа приложения с процессором приложения сторонних разработчиков будет добавлена к мобильному устройству, когда желательно запустить открытую OS, такую как Symbian. Эта платформа приложения будет расположена вместе с мобильной платформой в мобильном устройстве и будет управлять всеми приложениями, включающими в себя, например, мультимедийные приложения. Мобильная платформа, с другой стороны, будет отвечать за уменьшенный набор функциональных возможностей (включающих в себя все задачи мобильной связи, такие как беспроводной сетевой доступ) и, в основном, действует как платформа сетевого доступа. Между платформой приложения и мобильной платформой некоторый механизм интерфейса обеспечивает приложения на платформе приложения доступом (через OPA) к внутриплатформенным функциональным возможностям мобильной платформы, как будто бы эти приложения находились непосредственно на мобильной платформе.

В некоторых случаях может быть необходимо или желательно снабдить мобильное устройство более чем одной NAT. В этом отношении WO-A-00/22857 предлагает модульный подход, в котором различные платформы сетевого доступа в форме так называемых модулей сетевого доступа (таких как модуль локальной вычислительной сети (LAN) или модуль глобальной системы мобильной связи (GSM)) взаимосвязаны через коммуникационную шину согласно стандарту универсальной последовательной шины (USB). Другие модули, подключенные к этой коммуникационной шине, такие как модуль системы внутреннего видеонаблюдения (CCTV), могут затем избирательно передавать сигналы через LAN модуль, с одной стороны, или через GSM модуль - с другой.

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

Сущность изобретения

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

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

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

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

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

Интерфейсы управления могут отличаться от интерфейсов данных в отношении поддерживаемых скоростей передачи данных. Интерфейсы данных, такие как интерфейсы в соответствии с USB стандартом, обычно будут поддерживать более высокие скорости передачи данных, чем интерфейсы управления согласно, например, стандарту универсального асинхронного приемника/передатчика (UART) или стандарту универсального ввода/вывода (GPIO).

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

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

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

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

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

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

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

Путь связи между первым функциональным компонентом и вторым функциональным компонентом может использоваться для различных целей сигнализации. Согласно первому варианту, сигнализация относится к внутреннему хэндоверу между NAT, развернутыми на различных платформах сетевого доступа. Межплатформенная сигнализация может также происходить в контексте с доступом к смарт-карте или карте памяти, такой как карта универсальной интегральной схемы (UICC), в общем, и карта модуля идентификации абонента (SIM), в частности. Когда две платформы выполнены с возможностью выполнения задач модема, сигнализация, переносимая через установленный путь связи между различными функциональными компонентами, может включать в себя одну или несколько модемных команд, таких как команды, принадлежащие к набору команд Hayes (также называемых АТ командами). Конечно, этот путь связи может также использоваться для переноса любой другой сигнализации управления системой.

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

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

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

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

Способы, представленные здесь, могут быть реализованы в форме программного обеспечения, в форме аппаратного обеспечения или с использованием комбинированного программно-аппаратного подхода. Что касается программного подхода, обеспечен компьютерный программный продукт, содержащий части программного кода для выполнения этапов, представленных здесь, когда этот компьютерный программный продукт прогоняется на одном или нескольких вычислительных устройствах. Этот компьютерный программный продукт может храниться на считываемом компьютером носителе, таком как микросхема памяти, ПЗУ на компакт-диске, жесткий диск и т.д.

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

Эта платформенная система может быть выполнена с возможностью работы в соответствии со стандартом универсальной системы мобильной связи (UMTS). Кроме того, этот интерфейс может быть выполнен как USB интерфейс и/или интерфейс универсального асинхронного приемника/передатчика (UART).

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

Эти две платформенные системы, обсужденные выше, могут быть включены в единое устройство с общим контроллером или с отдельными управляющими объектами. Это устройство может быть выполнено как по меньшей мере одно из сетевой карты, портативного терминала и мобильного телефона. Эти функциональные компоненты могут быть реализованы как модули аппаратного или программного обеспечения, обеспечивающие RAT измерения уровня 1 (L1), SIM доступ, сигнализацию хэндовера (например, между внутренними NAT), сигнализацию модемных команд (например, с одной платформой, действующей как модем для приложения или функционального компонента, находящегося на другой платформе) и общие функциональные возможности управления платформами.

Краткое описание чертежей

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

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

Фиг.2 является схемой варианта осуществления второго устройства, включающего в себя варианты осуществления двухплатформенной системы;

Фиг.3 является блок-схемой, иллюстрирующей вариант осуществления первого способа;

Фиг.4 является блок-схемой, иллюстрирующей вариант осуществления второго способа;

Фиг.5а-5с являются схемами, иллюстрирующими переход от решения одноплатформенной системы к вариантам осуществления двухплатформенной системы;

Фиг.6 показывает схему примерного механизма формирования, простирающегося через варианты осуществления двухплатформенной системы;

Фиг.7 является схемой логического межплатформенного интерфейса;

Фиг.8 показывает схему вариантов осуществления двухплатформенной системы, связанных согласно первому варианту интерфейса;

Фиг.9 показывает схему вариантов осуществления двухплатформенной системы, связанных согласно второму варианту интерфейса;

Фиг.10 показывает схему вариантов осуществления двухплатформенной системы, связанных согласно третьему варианту интерфейса;

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

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

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

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

Описание предпочтительных вариантов осуществления

В следующем описании предпочтительных вариантов осуществления, с целями объяснения, а не ограничения, конкретные подробности (такие как конкретные интерфейсы, технологии сетевого доступа и последовательности этапов) изложены для того, чтобы обеспечить глубокое понимание данного изобретения. Специалисту в данной области техники будет ясно, что данное изобретение может быть реализовано в других вариантах осуществления, которые выходят за рамки этих конкретных подробностей. Например, хотя эти варианты осуществления будут, в основном, описаны в контексте со стандартами мобильной связи третьего и четвертого поколений, такими как UMTS и LTE стандарты, соответственно, будет ясно, что данное изобретение может также практиковаться в соединении с технологией мобильной связи второго поколения согласно, например, GSM стандарту.

Кроме того, специалистам в данной области техники будет ясно, что службы, функции и этапы, объясняемые ниже, могут быть реализованы с использованием функционирования программного обеспечения в сопряжении с программируемым микропроцессором, интегральной схемой прикладной ориентации (ASIC), процессором цифровых сигналов (DSP) или универсальным компьютером. Также будет ясно, что хотя следующие варианты осуществления будут, в основном, описаны в контексте со способами и устройствами, изобретение может быть также воплощено в компьютерном программном продукте, а также в системе, содержащей компьютерный процессор и память, связанную с этим процессором, причем эта память закодирована одной или несколькими программами, которые могут выполнять службы, функции и этапы, описанные здесь.

Далее, будет сделана ссылка на функции межплатформенного программного обеспечения в форме интерфейсов (таких как API и, в частности, OPA). Такие функции межплатформенного программного обеспечения обычно осуществляют абстракцию от внутриплатформенных интерфейсов. Это означает, что любые компоненты или интерфейсы вышеперечисленных интерфейсов межплатформенного программного обеспечения не должны подвергаться влиянию изменений компонентов и интерфейсов ниже интерфейсов межплатформенного программного обеспечения (т.е. должны быть независимы от них). Некоторые интерфейсы межплатформенного программного обеспечения могли бы быть прозрачными для некоторых сообщений или коммуникаций.

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

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

Фиг.1 схематично показывает некоторый вариант осуществления устройства 100, способного установить сетевой доступ через более чем одну NAT. Устройство 100 может быть выполнено как сетевая карта, как портативный терминал, такой как электронный секретарь (PDA), или как мобильный телефон.

Как показано на фиг.1, устройство 100 включает в себя два варианта осуществления платформенных систем 102, 104 сетевого доступа, выполненных с возможностью обеспечения сетевого доступа. Следует отметить, что устройство 100 могло бы содержать одну или несколько дополнительных платформенных систем (не показано), управляющих одной или несколькими дополнительными NAT и/или управляющих одним или несколькими процессорами приложений. Каждая платформенная система 102, 104 может быть реализована в форме отдельной ASIC и может содержать специализированный платформенный процессор. Следует отметить, что поскольку устройство 100 содержит две отдельные системы 102, 104 сетевого доступа, некоторое аппаратное обеспечение, например, компоненты электропитания и радиочастотные (RF) компоненты, может совместно использоваться обеими платформенными системами 102, 104.

Каждая платформенная система 102, 104 логически структурирована в три выделенных уровня. Конкретно, каждая платформенная система 102, 104 содержит уровень платформы сетевого доступа (далее также называемый «платформой») 106, 112, уровень межплатформенного программного обеспечения (далее также называемый «программным обеспечением промежуточного слоя») 108, 114, а также уровень приложения (далее также называемый «приложением») 110, 118. Каждый уровень 106, 108 и т.д. может логически содержать один или несколько компонентов, которые могут быть реализованы в форме программного обеспечения, в форме аппаратного обеспечения или как программно-аппаратная комбинация. Следует отметить, что в некоторых случаях некоторый уровень может не содержать какой-либо компонент, и в этой ситуации соответствующий уровень не нуждается в реализации вообще. В сценарии, показанном на фиг.1, это применяется к приложению 110 платформенной системы 102, а также к программному обеспечению 114 промежуточного слоя платформенной системы 104.

Все еще со ссылкой на фиг.1, платформа 112 платформенной системы 104 выполнена как платформа сетевого доступа, содержащая функциональный компонент 120, который выполнен с возможностью обеспечения и/или запроса основанной на платформе функции к удаленному функциональному компоненту, расположенному на платформе 106 сетевого доступа платформенной системы 102, и/или от него. Платформенная система 104 дополнительно содержит приложение 122 межплатформенной связи, логически установленное на (в значении «сверху») платформы 112 сетевого доступа и выполненное с возможностью управления сигнализацией между функциональным компонентом 120 и удаленным функциональным компонентом, находящимся на платформенной системе 102.

Платформа 112 дополнительно включает в себя интерфейс 124, выполненный с возможностью осуществления возможности контактирования приложения 122 межплатформенной связи с удаленной функцией 126 межплатформенного программного обеспечения. В варианте осуществления, показанном на фиг.1, функция 126 межплатформенного программного обеспечения расположена на уровне 108 межплатформенного программного обеспечения платформенной системы 102. Для осуществления возможности контактирования приложения 112 межплатформенной связи с функцией 126 межплатформенного программного обеспечения, межплатформенная связь будет установлена через интерфейс 124 и соответствующий интерфейс 128, принадлежащий платформе 106 платформенной системы 102.

Функция 126 межплатформенного программного обеспечения выполнена с возможностью обеспечения доступа к функциональному компоненту 130, расположенному вместе с интерфейсом 128 на платформе 106. Функция 126 межплатформенного программного обеспечения обычно может быть выполнена как API, и, в частности, как OPA, в связи с функциональным компонентом 130.

Платформенная система 104 также содержит контроллер 132, выполненный с возможностью установления пути связи 134 для переноса сигнализации между функциональным компонентом 120, находящемся на платформе 112 платформенной системы 104, с одной стороны, и функциональным компонентом 130, находящимся на платформе 106 платформенной системы 102, с другой стороны. Путь связи 134 простирается через приложение 122 межплатформенной связи и функцию 126 межплатформенного программного обеспечения.

Как показано на фиг.1, путь связи 134 начинается в пределах уровня 106 платформы платформенной системы 102 и заканчивается в пределах уровня 112 платформы платформенной системы 104. Путь связи 134, таким образом, позволяет осуществить межплатформенную связь между функциональным компонентом 120 и функциональным компонентом 130. В варианте осуществления фиг.1 термин «низкоуровневый» указывает, что функциональные компоненты 120, 130, связывающиеся друг с другом, расположены ниже уровней 110, 116 приложений и уровней 108, 114 межплатформенного программного обеспечения. Внутриплатформенные функциональности, обеспеченные одним или обоими функциональными компонентами 120, 130, могут, таким образом, разделяться через две платформенные системы 102, 104.

Что касается варианта осуществления, иллюстрированного на фиг.1, следует отметить, что контроллер 132 может быть расположен либо на платформенной системе 104, либо на платформенной системе 102. Контроллер 132 мог бы также быть распределенным компонентом с некоторыми функциональностями управления, обеспеченными платформенной системой 102, и другими функциональностями управления, обеспеченными платформенной системой 104. Согласно еще одному варианту, контроллер 132 может быть по меньшей мере частично компонентом устройства 100, внешнего как к платформенной системе 102, так и к платформенной системе 104.

Фиг.2 показывает дополнительный вариант осуществления устройства 100, содержащего варианты 102, 104 осуществления двухплатформенной системы. Те же ссылочные позиции, что и на фиг.1, используются для обозначения идентичных или подобных компонентов, и только различия между двумя вариантами осуществления фиг.1 и фиг.2 будут далее описаны более подробно.

Как явствует из фиг.2, наиболее важное отличие варианта осуществления, показанного на фиг.2, относится к функции 126 межплатформенного программного обеспечения, которая более не расположена в уровне 108 межплатформенного программного обеспечения платформенной системы 102. Точнее, функция 126 межплатформенного программного обеспечения была перемещена к уровню 114 межплатформенного программного обеспечения платформенной системы 104. С функцией 126 межплатформенного программного обеспечения теперь может контактировать приложение 122 межплатформенной связи через внутриплатформенный интерфейс (не показан на фиг.2), логически расположенный между приложением 122 межплатформенной связи и функцией 126 межплатформенного программного обеспечения. Подобно сценарию, показанному на фиг. 1, путь связи 134 простирается от функционального компонента 120 через приложение 122 межплатформенной связи и функцию 126 межплатформенного программного обеспечения к функциональному компоненту 130, расположенному на платформе 106 платформенной системы 102.

Согласно еще одному варианту осуществления устройства, не показанному в чертежах, приложение 122 межплатформенной связи могло бы быть перемещено от уровня 116 приложения платформенной системы 104 к уровню 110 приложения платформенной системы 102. В таком варианте осуществления функция 126 межплатформенного программного обеспечения будет расположена в пределах уровня 108 межплатформенного программного обеспечения платформенной системы 102 (как показано на фиг.1). Путь связи будет простираться от функционального компонента 120 платформенной системы 104 через межплатформенные интерфейсы 124, 128 к приложению 122 межплатформенной связи, и оттуда через функцию 126 межплатформенного программного обеспечения к функциональному компоненту 130 платформенной системы 102.

Теперь, два варианта осуществления способа для осуществления связи между функциональными компонентами, расположенными на различных платформах сетевого доступа, будут описаны со ссылкой на блок-схемы 300, 400 фиг.3 и 4. Эти варианты осуществления способа могут практиковаться посредством платформенных систем 102, 104, обсужденных выше, или посредством других платформенных систем, имеющих подходящую конфигурацию.

Теперь со ссылкой на блок-схему 300 фиг.3, первый вариант осуществления способа начинается с обеспечения первой платформы сетевого доступа, содержащей первый функциональный компонент, выполненный с возможностью обеспечения и/или запроса основанной на платформе функции ко второму функциональному компоненту, расположенному на второй платформе сетевого доступа, и/или от него (этап 302).

На следующем этапе 304 приложение межплатформенной связи устанавливается на первую платформу сетевого доступа. Это приложение межплатформенной связи адаптировано для управления сигнализацией между первым функциональным компонентом первой платформы сетевого доступа и вторым функциональным компонентом второй платформы сетевого доступа.

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

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

Согласно дополнительному варианту осуществления способа, иллюстрированному в блок-схеме 400 фиг.4, первая платформа сетевого доступа, содержащая первый функциональный компонент, обеспечивается на начальном этапе 402. Этот первый функциональный компонент выполнен с возможностью обеспечения и/или запроса основанной на платформе функции ко второму функциональному компоненту, расположенному на второй платформе сетевого доступа, и/или от него.

На следующем этапе 404 функция межплатформенного программного обеспечения устанавливается на первую платформу сетевого доступа. Эта функция межплатформенного программного обеспечения включает доступ приложения межплатформенной связи к первому функциональному компоненту.

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

Далее будет более подробно описана конфигурация платформ системы, а также процесс установления пути связи (и сигнализация, переносимая по установленному пути связи). Прежде всего, переход от платформенной системы, имеющей автономную конфигурацию, к платформенной системе, которая может работать в конфигурации двойного режима вместе с другой платформенной системой, расположенной вместе на том же устройстве, будет объяснен со ссылкой на фиг.5.

Фиг.5а иллюстрирует платформенную систему 202 в автономной конфигурации. Платформенная система 202 может использоваться в стандартных устройствах с только единой платформой сетевого доступа. Однако платформенная система 202 может также использоваться в некотором устройстве в комбинации с одной или несколькими платформенными системами, как будет обсуждаться в контексте с фиг.5b и 5с позже. Платформенная система 202, показанная на фиг.5а, может быть получена из любой из платформенных систем 102, 104, показанных на фиг.1 и 2.

Как показано на фиг.5а, платформенная система 202 содержит платформу 204 сетевого доступа на самом нижнем уровне, уровень межплатформенного программного обеспечения с функцией 206 межплатформенного программного обеспечения, а также уровень приложения с приложением 208.

В варианте осуществления, показанном на фиг.5а, платформа 204 сетевого доступа поддерживает RAT в соответствии с LTE стандартом. LTE платформа 204 содержит два функциональных компонента 210, 212 («Модуль Х» и «Модуль Z»). Функциональные компоненты 210, 212 адаптированы для обеспечения и/или запроса основанной на платформе функции друг от друга. Такие основанные на платформе функции могут включать в себя связанные с RAT функциональности, такие как измерения уровня 1 (L1), сигнализация хэндовера, SIM доступ или общие функциональности управления системой на уровне платформы.

В LTE варианте осуществления, показанном на фиг.5а, функция 206 межплатформенного программного обеспечения выполнена как LTE OPA. LTE OPA, реализуемый функцией 206 межплатформенного программного обеспечения, содержит API функции, которые должны быть обеспечены для приложения 208 для управления LTE платформой 204 (включающие в себя, но не ограниченные этим, управление функциональными компонентами 210 и 212).

Платформа 204 и функция 206 межплатформенного программного обеспечения могут быть интегрированы в единую ASIC, как обычно известно из US 7149510 В2 (см. фиг.2 этой заявки), включенной здесь в качестве ссылки, когда речь идет о возможной аппаратной и программной реализации платформенной системы 202 и одной или нескольких дополнительных платформенных систем, обсуждаемых здесь. Конкретно, такая ASIC может содержать LTE контроллер прямой передачи и центральный процессор (CPU), поддерживающий открытую или оригинальную OS, а также необходимое программное обеспечение промежуточного слоя. Функциональные компоненты 110 и 112 могут быть реализованы посредством ASIC в форме программного обеспечения, в форме аппаратного обеспечения или как программно-аппаратная комбинация.

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

Фиг.5b показывает такой двухплатформенный сценарий, в котором платформенная система 202 фиг.5а расположена вместе с дополнительной подобной платформенной системой 220 в едином устройстве. Эта дополнительная платформенная система 220, показанная на фиг.5b, содержит платформу 222 сетевого доступа, обеспечивающую поддержку для RAT согласно стандарту UMTS.

В двухплатформенном варианте осуществления, показанном на фиг.5b, приложение 208' платформенной системы 220 может нуждаться в доступе к функциональному компоненту 210 («Модуль Х»), расположенному на другой платформенной системе 202. Приложение 208' может принадлежать к открытой среде приложений. Кроме того, функциональный компонент 210, обеспеченный LTE платформой 204 платформенной системы 202, может нуждаться в доступе к себе посредством (или может нуждаться в доступе к) функционального компонента 212' («Модуль Y»), обеспеченного UMTS платформой 222 платформенной системы 220. Такие и подобные сценарии связи требуют реализации эффективного способа межплатформенной связи.

Как обсуждалось выше в контексте с фиг.1-4, такой способ внутриплатформенной связи может включать в себя функции межплатформенного программного обеспечения и приложение межплатформенной связи. С обращением к фиг.5b уровень межплатформенного программного обеспечения, включающий первую функцию 206' межплатформенного программного обеспечения, обеспечен с этой целью. Функция 206' межплатформенного программного обеспечения позволяет приложению 208' платформенной системы 220 осуществить удаленное управление функциональным компонентом 210, расположенным на платформенной системе 202. Функция 206' межплатформенного программного обеспечения платформенной системы 220 была получена из соответствующей функции 206 межплатформенного программного обеспечения платформенной системы 202. Как показано на фиг.5b, платформенная система 220 содержит дополнительную функцию 223 межплатформенного программного обеспечения, которая позволяет приложению 208' осуществлять управление функциональностями локальной UMTS платформой 222, включающее в себя управление локальным функциональным компонентом 212'.

Как уже отмечалось, может возникнуть необходимость в межплатформенной связи низкого уровня между функциональным компонентом 210 платформенной системы 202 и функциональным компонентом 212' платформенной системы 220. В таком случае может быть установлен путь внутриплатформенной связи между функциональным компонентом 212' и функциональным компонентом 210. Этот путь связи (не показан на фиг.5b) включает в себя приложение 224 межплатформенной связи, обеспеченное в собственной системе команд посредством платформенной системы 220, а также по меньшей мере одну импортируемую 214' или собственную функцию 226 межплатформенного программного обеспечения на уровне межплатформенного программного обеспечения.

Что касается уровня межплатформенного программного обеспечения, на фиг.5b могут быть дифференцированы два случая. Когда функциональный компонент 212' платформенной системы 220 вызывает некоторую функцию, обеспеченную посредством функционального компонента 210 платформенной системы 202, путь связи простирается от функционального компонента 212' через функцию 226 межплатформенного программного обеспечения, приложение 224 межплатформенной связи и функцию 214' межплатформенного программного обеспечения к функциональному компоненту 210. Когда, с другой стороны, функциональный компонент 210 вызывает некоторую функцию, обеспеченную посредством функционального компонента 212', путь связи простирается от функционального компонента 210 через функцию 214 межплатформенного программного обеспечения, приложение 224 межплатформенной связи и функцию 226 межплатформенного программного обеспечения к функциональному компоненту 212'.

В основном, функция 214' межплатформенного программного обеспечения содержит API (OPA) для доступа к функциям функционального компонента 210, и функция 226 межплатформенного программного обеспечения содержит API (OPA) для доступа к функциям функционального компонента 212'. Функция 214' межплатформенного программного обеспечения может быть получена из функции 214 межплатформенного программного обеспечения посредством ее импорта от платформенной системы 202 в форме программного кода, в форме удаленной визуализации, как обсуждается ниже в контексте с фиг.6, или в любой другой форме.

Следует отметить, что для ясности межплатформенные интерфейсы для экспортирования и импортирования функций 206', 214' межплатформенного программного обеспечения и для установления пути связи не показаны на фиг.5b. Такие интерфейсы будут обсуждаться ниже в контексте с фиг.8-10.

В сценариях межплатформенной связи, описываемых здесь, обе функции 214' и 226 межплатформенного программного обеспечения могут быть включены одновременно в путь связи. Функция 214' межплатформенного программного обеспечения (L2U OPA) включает в себя все функции/службы LTE платформенной системы 202 для межплатформенной связи, и функция 226 межплатформенного программного обеспечения (U2L OPA) включает в себя все функции/службы UMTS платформенной системы 220 для межплатформенной связи. Задача функций 214', 226 межплатформенного программного обеспечения будет теперь примерно описана по отношению к внутренним RAT (IRAT) измерениям на LTE платформе 204, с одной стороны, и на UMTS платформе 222, с другой.

Начиная со сценария LTE IRAT измерений, будем предполагать, что функциональный компонент 210 LTE платформы 204 способен обеспечивать IRAT измерения, тогда как функциональный компонент 212' на UMTS платформе 222 способен запрашивать такие измерения. В этом примере функция 214' межплатформенного программного обеспечения обеспечивает для функционального компонента 212' службу (или интерфейс для) запрашивания LTE IRAT измерений от функционального компонента 210 и обеспечивает, после того, как измерения на LTE RAT были проведены, соответствующие результаты для функционального компонента 212'. Функция 226 межплатформенного программного обеспечения, с другой стороны, обеспечивает для функционального компонента 212' возможность (или интерфейс для) подписки на то событие, что UMTS платформа 222 желает запустить RAT измерения на LTE RAT. Также, функция 226 межплатформенного программного обеспечения обеспечивает службу (или интерфейс) для функционального компонента 212' продвижения соответствующих результатов измерений к UMTS платформе 222.

В другом случае UMTS IRAT измерений будет предполагаться, что функциональный компонент 212' на UMTS платформе 222 способен выполнять такие измерения, тогда как функциональный компонент 210 на LTE платформе 204 способен запрашивать такие измерения. В таком случае функция 226 межплатформенного программного обеспечения обеспечивает для функционального компонента 210 службу запрашивания IRAT измерений на UMTS RAT и обеспечивает, после того, как измерения на UMTS RAT были завершены функциональным компонентом 212', соответствующие результаты для функционального компонента 210. Функция 214' межплатформенного программного обеспечения обеспечивает для функционального компонента 210 возможность подписки на то событие, что LTE платформа 204 (функциональный компонент 210) желает запустить IRAT измерения на UMTS RAT. Кроме того, функция 214 межплатформенного программного обеспечения обеспечивает службу продвижения результатов измерений на UMTS RAT к функциональному компоненту 210 на LTE платформе 204.

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

Фиг.5с показывает другой двухплатформенный сценарий, который был получен из сценария, показанного на фиг.5b. В отличие от сценария, показанного на фиг.5b, здесь предполагается, что о внутренней структуре комбинированной UMTS платформы и среды 222' приложения платформенной системы 220 не известно никаких конкретных подробностей. Это может иметь место, так как платформенная система 220 не является оригинальной системной платформой производителя устройства, а была получена от другого торговца. Однако идея экспортирования (включая визуализацию) функций 206, 214 межплатформенного программного обеспечения от оригинальной платформенной системы 202 к платформенной системе 220 стороннего разработчика все еще применима для того, чтобы позволить функциональному компоненту 212'' (или любым приложениям в пределах среды 222') получить доступ к функциональному компоненту 210 платформенной системы 202.

Что касается импорта функций межплатформенного программного обеспечения, выше уже обсуждалось, что одно решение состоит в переносе программного кода одной или нескольких функций межплатформенного программного обеспечения от платформенной системы 202 к платформенной системе 220. Другая возможность будет теперь объяснена со ссылкой на фиг.6.

Фиг.6 схематично показывает подход для обеспечения приложения 208' межплатформенной связи фиг.5b и 5с доступом к функции 214' межплатформенного программного обеспечения и к лежащим в основе функциональным компонентам (т.е. для «импортирования» функции 214 межплатформенного программного обеспечения). Фиг.6 иллюстрирует аппаратную конфигурацию платформенных систем 202 и 220 на уровне центрального процессора (CPU).

В основном, механизм, названный «Распределенная модель функции», (DFM) используется для того, чтобы сделать удаленную функцию 214 межплатформенного программного обеспечения платформенной системы 202 видимой (имитирующей «локальную» функцию 214' межплатформенного программного обеспечения) для другой платформенной системы 220. Другими словами, DFM механизм используется для логической взаимосвязи двух CPU - LTE платформенной системы 202 и UMTS платформенной системы 220 таким образом, что любые функциональные компоненты (не показаны на фиг.6) на уровне платформы платформенной системы 220 обеспечиваются доступом, через приложение 208' межплатформенной связи и функцию 214 межплатформенного программного обеспечения, к любым функциональным компонентам (не показаны на фиг.6), расположенным на уровне платформы платформенной системы 202. В этом отношении комбинация DFM механизма и функции 214 межплатформенного программного обеспечения может быть интерпретирована как составляющая «удаленную» функцию 214' межплатформенного программного обеспечения, иллюстрированную на фиг.5b и 5с. С другой стороны, DFM механизм может рассматриваться как средство для «экспортирования» функции 214 межплатформенного программного обеспечения от платформенной системы 202 к платформенной системе 220. В основном, DFM механизм делает возможным для любого функционального компонента на уровне платформы платформенной системы 220 прозрачный доступ к любому функциональному компоненту, расположенному на уровне платформы платформенной системы 202, для которой была определена соответствующая функция (API или OPA) 214 межплатформенного программного обеспечения.

Как показано на фиг.6, между двумя платформенными системами 202, 220 существует физическая линия связи 230. Физическая линия связи 230 простирается между одним или несколькими физическими интерфейсами 232 платформенной системы 202 и одним или несколькими физическими интерфейсами 234 платформенной системы 220. Физические интерфейсы 232, 234 могут быть выполнены как интерфейсы данных (например, согласно стандарту USB), как интерфейсы управления (например, согласно стандарту UART или GPIO) или как оригинальные интерфейсы (PIF). Интерфейсы данных обычно будут поддерживать более высокие скорости передачи, чем интерфейсы управления, за счет более сложных требований к аппаратному обеспечению. Примерные комбинации интерфейсов будут описаны ниже со ссылкой на фиг.8-10.

Все еще со ссылкой на фиг.6 логические интерфейсы «платформенный CPU - платформенный CPU» (PPIF) 236, 238 расположены выше физических интерфейсов 232, 234. PPIF 236, 238 составлены посредством управляющих программных модулей, которые связываются с логическими и физическими драйверами уровня доступа к аппаратному обеспечению (HAL) для взаимосвязи двух CPU платформенных систем 202, 220. На основе PPIF модулей 236, 238, логическая PPIF линия связи 240 может быть установлена логически поверх физической линии связи 230. Конфигурация PPIF модулей 236, 238 показана на фиг.7.

Как показано на фиг.7, каждый PPIF модуль 236, 238 включает в себя нижний уровень 300 с драйверами физического интерфейса (HAL драйверами), за которыми следуют уровень 302 логических драйверов и уровень доступа к PPIF данным, содержащий подуровень 304 управления и служебный подуровень 306. Подуровень 304 управления управляет открытием и закрытием служб в служебном подуровне 306, маршрутизацией входящих и исходящих пакетов относительно индивидуальных служб («типов линий связи») в служебном уровне и связанными задачами мультиплексирования. Кроме того, подуровень 304 управления отвечает за логику перехода между неактивным и активным режимами для индивидуальных служб, обеспеченных служебным подуровнем 306.

Служебный подуровень 306 поддерживает множество различных потоков данных. В данном контексте служба 306а DFM линии связи представляет особый интерес. В основном, служба 306а DFM линии связи управляет PDU транспортом между каждым из PPIF модулей 236, 238 и связанным DFM модулем 240, 242, соответственно (см. фиг.6). Служба 306а DFM линии связи отвечает за создание и разрушение DFM линий связи по направлению к функции 214 межплатформенного программного обеспечения и приложению 208' межплатформенной связи и за посылку и принятие данных на этих DFM линиях связи.

Служба 306b виртуального внешнего интерфейса (VEI) служебного подуровня 306 управляет виртуальными портами связи (COM) для передачи с коммутацией пакетов данных (PS) и передачи данных с коммутацией каналов (CS). Кроме того, VEI служба 306b поддерживает обмен АТ модемных команд между двумя платформенными системами 202, 220 фиг.6. Дополнительные службы, обеспеченные служебным подуровнем 306, включают в себя обработку необработанных CS данных от сети и их передачу к видеоприложению (видеослужба 306с), визуализацию отладочных распечаток для удаленной системной платформы (служба 306d отладки), транспорт пакетов данных пользователей Интернет-протокола (IP) (служба 306е PS данных), а также управление PPIF линией связи (включая декодирование PPIF команд) и управление мощностью (служба 306f управления).

Опять со ссылкой на фиг.6 индивидуальные компоненты DFM модулей 240, 242 будут теперь описаны более подробно. Как уже отмечалось выше, DFM модули 240, 242 полагаются на PPIF модули 236, 238 для установления одной или нескольких логических DFM линий связи 244. В основном, DFM модуль 242 платформенной системы 220 (под управлением приложения 208' межплатформенной связи) отвечает за создание любой DFM линии связи. Как только DFM3 линия связи была создана, DFM сигнализация между двумя платформенными системами 202, 220 является симметричной. DFM модуль 242, связанный с приложением 208' межплатформенной связи, будет также отвечать за закрытие DFM линии связи.

Центральным компонентом каждого DFM модуля 240, 242 является диспетчер модуля-посредника и фиктивного модуля (PSM) 246, 248. PSM 246, 248 реализует функциональность, которая делает возможной визуализацию (или «экспорт» и «импорт») интерфейсов локальных функциональных компонентов, тем самым обеспечивая основанные на платформе функции для удаленной платформенной системы. PSM 246, 248, в частности, отвечают за создание модулей посредников и фиктивных модулей для связывающихся функциональных компонентов. На каждую функцию (OPA интерфейс) 214 межплатформенного программного обеспечения будет приходиться одна пара «модуль-посредник - фиктивный модуль» (или «линия связи»), и каждая пара «модуль-посредник - фиктивный модуль» регистрируется в PSM 246, 248. Обработка модулей-посредников и фиктивных модулей является симметричной в пределах PSM 246, 248. PSM 246, 248, таким образом, создает линию связи «модуль-посредник/фиктивный модуль” на OPA интерфейс, и он также отвечает за создание и удаление экземпляров OPA интерфейсов (после делегирования компонентными диспетчерами 250, 252).

Модуль-посредник 254 является компонентом, который принимает запросы интерфейсов от некоторого локального компонента (такого как приложение 208' межплатформенной связи) и перенаправляет запросы интерфейсов к связанному удаленному фиктивному модулю 256. Фиктивный модуль 256 имеет указатель интерфейса, ссылающийся на конкретный функциональный компонент, так что он может использовать функцию, обеспеченную этим функциональным компонентом через соответствующий OPA интерфейс (функцию межплатформенного программного обеспечения) 214. Когда некоторый функциональный компонент (или связанное приложение 208' межплатформенной связи) вызывает некоторую функцию (например, некоторый способ) некоторого удаленного функционального компонента, он в действительности вызывает модуль-посредник 254, который вызывает связанный фиктивный модуль 256, который, наконец, вызывает (через функцию 214 межплатформенного программного обеспечения) эту функцию этого удаленного функционального компонента. Посредством использования DFM механизма весь этот межплатформенный процесс выполняется прозрачно со стороны функциональных компонентов.

Дополнительным принципом, лежащим в основе DFM механизма, является так называемый принцип компоновки. Компоновка означает процесс упаковки идентификатора вызывающего функционального компонента (или идентификатора связанного приложения 208' межплатформенной связи), идентификатора вызываемой функции (или вызываемого функционального компонента), а также всех входных параметров вызываемой функции в буфер. Этот процесс обычно будет выполняться модулем-посредником 254 или приложением 208' межплатформенной связи. Этот буфер затем переадресуется к PSM 248, который помещает его в некоторый PDU согласно оригинальному стандарту или стандарту открытого протокола. Этот PDU затем посылается по DFM линии связи 244 к удаленному PSM 246. Удаленный PSM 246 распаковывает этот PDU и посылает, таким образом, восстановленный буфер к фиктивному модулю 256. В фиктивном модуле 256 этот буфер декомпонуется, и связанная функция вызывается. Компоновка и декомпоновка осуществляется одним и тем же способом для выходных параметров (возвращенных значений) вызываемой функции, как только они станут доступными. В этом отношении модуль-посредник 258 обратного вызова автоматически запустит фиктивный модуль 260 обратного вызова способом, подобным описанному выше относительно модуля-посредника 254 и фиктивного модуля 256.

Как показано на фиг.6, каждый DFM модуль 240, 242 включает в себя компонентный диспетчер (СМ) 250, 252. СМ 250, 252 отвечает за управление всеми функциональными компонентами. С этой целью каждый СМ 250, 252 хранит список всех локальных и удаленных функциональных компонентов платформенных систем 202, 220, для которых был создан некоторый случай. Для внешних или удаленных компонентов СМ 250, 252 возвращает идентификатор устройства (например, платформенной системы), причем этот удаленный компонент расположен к локальному PSM 246, 248 таким образом, что PSM 246, 248 может сам создать этот соответствующий компонент.

DFM модуль 240 платформенной системы 202 дополнительно содержит диспетчер 262 процесса. Диспетчер 262 процесса создает и сбрасывает процессы для обработки некоторого входящего запроса от платформенной системы 220 (т.е. от удаленного CPU). Создание и сбрасывание процессов предотвращает блокирования DFM модуля 246.

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

Фиг.8 теперь показывает схему индивидуальных физических интерфейсов, по которым будет установлена физическая линия связи 230 на фиг.6 между двумя платформенными системами 202 и 220. Описание тех компонентов платформенных систем 202, 220, которые уже были обсуждены выше в контексте с фиг.5b, 5с и 6, будет опущено.

Как показано на фиг.8, две платформенные системы 202, 220 связаны параллельно посредством USB интерфейсов 232а, 234а, с одной стороны, и UART интерфейсов 232b, 234b, с другой стороны. USB интерфейсы 232а, 234а составляют высокоскоростные интерфейсы по пользовательским данным, основанные на стандарте USB Ethernet. USB линия связи (которая является частью подключения 270 данных, указанного стрелками со сплошной линией), установленная через USB интерфейсы 232а, 234а, обеспечивает сетевой доступ согласно стандарту LTE к приложениям, находящимся на UMTS платформе 222. Такими приложениями могут быть либо приложения 208', установленные поверх UMTS платформы, либо внутриплатформенные приложения 208'. Подключение 270 данных простирается, на стороне LTE платформы 204, через модуль 272 сигнализации LTE сети (NS), модуль 274 кадрирования Ethernet, а также USB интерфейс 232а. На стороне UMTS платформы 222 подключение 270 данных простирается через USB интерфейс 234а, модуль кадрирования Ethernet, а также TCP/IP модуль 278.

Подключение 280 управления, указанное стрелками с пунктирными линиями, простирается через два UART интерфейса 232b, 234b. Первая ветвь этого подключения 280 управления простирается между функциональным компонентом 210 LTE платформы 204 и функциональным компонентом 212' UMTS платформы 222. Примерные сценарии сигнализации, использующие эту ветвь подключения 280 управления, будут обсуждаться позже со ссылкой на фиг.11-14.

Вторая ветвь подключения 280 управления простирается от приложения 208' UMTS платформы 222 к функции 206 межплатформенного программного обеспечения LTE платформы 204 (которая соответствует импортированной функции 206' межплатформенного программного обеспечения, показанной поверх UMTS платформы 222). Функции 206 и 206' межплатформенного программного обеспечения были определены для доступа к функциональному компоненту 210 или любому другому функциональному компоненту LTE платформы 204. Основное различие между функциями 214 и 206 межплатформенного программного обеспечения относится к тому факту, что функция 206 (LTE OPA) межплатформенного программного обеспечения содержит службы, обеспеченные для некоторого приложения для того, чтобы управлять LTE платформой 204, например, параметрами настройки, подобными «радио включено/выключено», выбор сети и т.д. Функция 214 межплатформенного программного обеспечения (L2U OPA) содержит дополнительные службы для межплатформенной связи LTE платформы, например, для управления системой, доступа к SIM, IRAT механизмами хэндовера и, возможно, обмена АТ командами.

Хотя USB интерфейсы 232а, 234а поддерживают высокие скорости передачи данных на подключении 270 данных, на подключении 280 управления обычно будут иметь место гораздо более низкие скорости передачи данных, и по этой причине для межплатформенной сигнализации управления на подключении 280 управления используются менее сложные UART интерфейсы 232b, 234b.

В сценарии интерфейсов, показанном на фиг.9, два UART интерфейса 232b, 234b на фиг.8 были опущены. В этом сценарии, как подключение управления, так и подключение данных простираются по двум USB интерфейсам 232а, 234а.

В еще одном сценарии интерфейсов, показанном на фиг.10, UART интерфейсы 232b, 234b дополнительно используются для переноса низкоскоростных пользовательских данных, тогда как высокоскоростные пользовательские данные переносятся через USB интерфейсы 232а, 234а.

В сценариях интерфейсов, показанных на фиг.8 и 10, перенос IP данных (включая пользовательские данные и данные приложений) обрабатывается отдельно от сигнализации управления. Для IP данных USB Ethernet механизм используется непосредственно как транспортное средство между LTE платформой 204 и UMTS платформой 222. Этот подход имеет среди других то преимущество, что транспортный механизм для IP данных между двумя платформами 204, 222 является тем же самым, что и механизм, который также может использоваться между одной из платформ 204, 222 и внешним устройством, таким как персональный компьютер (РС) или портативный компьютер, когда одна или обе платформы 204, 222 находятся, например, на сетевой карте, связанной с этим РС или портативным компьютером.

Следует отметить, что межплатформенная сигнализация управления, касающаяся настройки, сброса и т.д. переноса IP данных через USB Ethernet службу, конечно, может управляться через основанную на UART сигнализацию управления. Эта сигнализация управления может также использоваться для визуализации и доступа к функциям уровня межплатформенного программного обеспечения на удаленных платформах для осуществления возможности связи между функциональными компонентами на уровне платформы. Как показано на фиг.10, интерфейсы 232b, 234b управления, возможно, могут использоваться для переноса низкоскоростных IP данных, если это необходимо.

Что касается PPIF функциональностей, показанных на фиг.8-10, то физические интерфейсы могут быть адаптированы для уровня PPIF драйверов таким образом, что каналы связи могут прозрачно использовать различные типы подключений (например, различные физические интерфейсы, подобные USB или UART). Преобразование служб связи в физические интерфейсы может быть свободно настраиваемым. Как показано на фиг.9, возможное преобразование служб связи в USB и UART интерфейсы 232а, 234а, 232b, 234b могло бы выбираться таким образом, чтобы высокоскоростные IP данные переносились через USB интерфейсы 232а, 234а, тогда как низкоскоростные IP данные сигнализации управления переносились через UART интерфейсы 232b, 234b.

Теперь, несколько примерных сценариев межплатформенной сигнализации будут обсуждаться со ссылкой на фиг.11-14. В каждом случае предполагается, что первый функциональный компонент 210, расположенный на LTE платформе 204, получает доступ или вызывает (или к нему осуществляется доступ или он вызывается) функциональный компонент 212', расположенный на UMTS платформе 222. В контексте этих вариантов осуществления сигнализации будет введен виртуальный функциональный компонент («Виртуальный модуль Y») 212''', реализованный на LTE платформе 204. В основном, виртуальный функциональный компонент 212''' имитирует для функционального компонента 210 существование функционального компонента 212' на LTE платформе 204. В этом контексте виртуальный функциональный компонент 212' выполняет, в основном, задачи преобразования и действует как модуль-посредник перед функциональным компонентом 210. Если необходимо, подобный виртуальный функциональный компонент («Виртуальный модуль Х», не показанный на чертежах) может быть установлен на UMTS платформе 222 как модуль-посредник перед функциональным компонентом 212'.

В каждом из следующих вариантов осуществления сигнализации будет предполагаться, что функция 214' межплатформенного программного обеспечения на стороне UMTS платформы 222 была импортирована от UMTS платформы 222 с использованием DFM механизма, обсужденного выше в контексте с фиг.6. Это означает, что функциональный компонент 214' только виртуально существует на стороне UMTS платформы 222, тогда как действительный программный код, лежащий в основе функционального компонента 214', находится в форме функционального компонента 214 на стороне LTE платформы 204. Конечно, в альтернативном сценарии, не показанном на фиг.11-14, соответствующий программный код может быть уже установлен в собственной системе команд на стороне UMTS платформы 222 или может быть физически перенесен от LTE платформы 204 к UMTS платформе 222 либо во время изготовления устройства, либо после этого.

Теперь со ссылкой на фиг.11, сначала будет описан сценарий сигнализации, включающий в себя запрос параметров шифрования от некоторого функционального компонента в форме SIM модуля 212' на UMTS платформе 222 функциональным компонентом в форме модуля 210' сетевой сигнализации (NS) на LTE платформе 204.

В качестве необходимого условия этого первого сценария сигнализации приложение 224 межплатформенной связи подписывается на связанные события сигнализации виртуального функционального компонента 212''' через функцию 214' межплатформенного программного обеспечения, как указано этапами (1) и (2) сигнализации. Соответствующее сообщение подписки, посланное от приложения 224 межплатформенной связи к виртуальному функциональному компоненту 212''', информирует виртуальный компонент 212''', что приложение 224 межплатформенной связи должно быть уведомлено, если NS модуль 210 запрашивает какие-либо параметры шифрования.

Этап (3) сигнализации указывает передачу такого запроса параметров шифрования от NS модуля 210 к виртуальному функциональному компоненту 212''' (так как NS модуль на LTE платформе 204 предполагает, что удаленный SIM модуль 212' расположен вместе с NS модулем на LTE платформе 204). Приложение 224 межплатформенной связи ранее подписалось на такие события сигнализации от NS модуля 210, и виртуальный функциональный компонент 212''', таким образом, преобразует (или транслирует) запрос, принятый от NS модуля 210 в заданное событие сигнализации. Этот этап преобразования может включать в себя упаковку запроса, принятого на этапе (3) сигнализации в сообщение о событии, имеющее некоторый формат, который может быть считан приложением 224 межплатформенной связи. На этапах (4) и (5) сигнализации это сообщение о событии, включающее в себя преобразованный запрос, переносится от виртуального функционального компонента 212''' через функцию 214/межплатформенного программного обеспечения к приложению 224 межплатформенной связи.

После принятия сообщения о событии от виртуального функционального компонента 212''' приложение 224 межплатформенной связи повторно преобразует (или повторно транслирует) сообщение о событии в некоторый запрос, который может быть считан SIM модулем 212'. Соответствующий запрос параметров шифрования затем пересылается через дополнительную функцию 226 межплатформенного программного обеспечения к SIM модулю 212', находящемуся на UMTS платформе 222, как указано этапами (6) и (7) сигнализации.

На следующем этапе SIM модуль 212' исполняет принятый запрос и посылает ответное сообщение вместе с запрошенными параметрами шифрования через функцию 226 межплатформенного программного обеспечения к приложению 224 межплатформенной связи. Это указано этапами (8) и (9) сигнализации.

Приложение 224 межплатформенной связи преобразует принятое ответное сообщение в сообщение запроса, которое может быть интерпретировано виртуальным функциональным компонентом 212'''. Это сообщение запроса пересылается на этапах (10) и (11) сигнализации через функцию 214' межплатформенного программного обеспечения к виртуальному функциональному компоненту 212'''. В этом отношении функция 214' действует как API в отношении виртуального функционального компонента 212'''.

Виртуальный функциональный компонент 212''' повторно преобразует сообщение запроса, принятое от приложения 224 межплатформенной связи в некоторый формат, ожидаемый NS модулем 210. Соответствующее ответное сообщение, включающее в себя запрошенные параметры шифрования, наконец, посылается на этапе (12) сигнализации к NS модулю 210.

Дополнительный вариант осуществления сигнализации, относящийся к передаче события сигнализации от функционального компонента 212', расположенного на UMTS платформе 222, к другому функциональному компоненту 210, расположенному на LTE платформе 204, будет теперь описан в контексте с фиг.12. Соответствующим событием уровня платформы может быть некоторое изменение SIM состояния, детектированное некоторым функциональным компонентом в форме SIM модуля 212' на UMTS платформе 222. Это изменение SIM состояния будет нуждаться в сигнализации к функциональному компоненту 210 на LTE платформе 204. Функциональный компонент 210 и/или приложение 224 межплатформенной связи, возможно, могут подписаться заранее на такое событие, как обсуждалось выше в контексте сценария сигнализации по фиг.11.

Как только SIM модуль 212' детектировал некоторое изменение SIM состояния, он генерирует соответствующее сообщение о событии и пересылает его через функцию 226 межплатформенного программного обеспечения к приложению 224 межплатформенной связи, как указано этапами (1) и (2) сигнализации.

Приложение 224 межплатформенной связи преобразует принятое сообщение о событии в сообщение запроса, которое может быть считано виртуальным функциональным компонентом 212''' LTE платформы 204. Соответствующее сообщение запроса затем пересылается на этапах (3) и (4) сигнализации через функцию 214' межплатформенного программного обеспечения к виртуальному функциональному компоненту 212'''.

Виртуальный функциональный компонент 212''' повторно преобразует это сообщение запроса в сообщение о событии (т.е в некоторый формат, который может быть прочитан функциональным компонентом 210) и посылает результирующее сообщение о событии на этапе (5) сигнализации к функциональному компоненту 210.

Другой сценарий сигнализации, относящийся к сообщению запроса, посланному от функционального компонента 212' (здесь некоторого IP модуля), расположенного в пределах UMTS платформы 222, к функциональному компоненту 210, расположенному в пределах LTEe платформы 204, будет теперь описан со ссылкой на фиг.13. Таким сообщением запроса мог бы быть, например, запрос активации/деактивации контекста протокола пакетных данных (PDP), посланный от некоторого функционального компонента в форме некоторого IP модуля 212' на UMTS платформе 222 к некоторому функциональному компоненту в форме некоторого NS модуля на LTE платформе 204.

В качестве необходимого условия приложение 224 межплатформенной связи подписалось на события сигнализации этого IP модуля 212' и виртуального функционального компонента 212'''. Соответствующие сообщения подписки переносятся на этапах (1а) и (2а) сигнализации, а также (1b) и (2b), соответственно.

Основанный на событии процесс начинается, когда IP модуль 212' детектирует событие активации/деактивации PDP контекста и уведомляет приложение 224 межплатформенной связи об этом событии. Соответствующее уведомление переносится через функцию 226 межплатформенного программного обеспечения, как указано этапами (3) и (4) сигнализации. Это событие заменит соответствующий запрос, непосредственно перенесенный к NS модулю 210 в автономной платформенной конфигурации, в которой оба модуля 210, 212' расположены вместе на одной и той же платформе.

Приложение межплатформенной связи опять преобразует это событие в некоторый запрос, который может быть интерпретирован виртуальным функциональным компонентом 212'''. Результирующее сообщение запроса пересылается к виртуальному функциональному компоненту 212''' через функцию 214' межплатформенного программного обеспечения на этапах (5) и (6) сигнализации.

Виртуальный функциональный компонент 212''' пересылает принятое сообщение запроса к NS модулю 210. В этом случае виртуальный функциональный компонент 212''' не нуждается (в обязательном) выполнении каких-либо задач преобразования. После принятия сообщения запроса от виртуального функционального компонента 212''' NS модуль 210 генерирует некоторое ответное сообщение и передает это ответное сообщение на этапе (8) сигнализации к виртуальному функциональному компоненту 212'''. Виртуальный функциональный компонент 212''' затем преобразует принятое ответное сообщение в сообщение о событии, которое может быть интепретировано приложением 224 межплатформенной связи, и посылает это сообщение о событии к приложению 224 межплатформенной связи через функцию 214' межплатформенного программного обеспечения, как указано этапами (9) и (10) сигнализации.

Приложение 224 межплатформенной связи повторно преобразует сообщение о событии, принятое от виртуального функционального компонента 212''', в сообщение запроса, которое может прочесть IP модуль 212', и пересылает, таким образом, сгенерированное сообщение запроса, через функцию 226 межплатформенного программного обеспечения, к IP модулю 212'. Соответствующие этапы (11) и (12) сигнализации показаны на фиг.13. Принятие сообщения запроса IP модулем 212' заменяет соответствующее ответное сообщение, которое было бы непосредственно получено от NS модуля 210, если бы NS модуль 210 был расположен вместе с IP модулем на UMTS платформе 222.

Финальный пример сигнализации будет теперь описан со ссылкой на фиг.14. Этот пример сигнализации относится к передаче некоторого сообщения о событии от функционального компонента 210, расположенного на LTE платформе 204, к удаленному функциональному компоненту 212', расположенному на UMTS платформе 222. Такое сообщение о событии могло бы указывать на изменение состояния PDP контекста, которое обычно сигнализируется от некоторого функционального компонента в форме NS модуля 210 на LTE платформе 204 к некоторому функциональному компоненту в форме IP модуля 212' на UMTS платформе 222.

Со ссылкой на фиг.11 эта сигнализация начинается с детектирования NS модулем 210 изменения состояния PDP контекста. После детектирования такого изменения состояния NS модуль 210 генерирует соответствующее сообщение о событии и передает это сообщение о событии на этапе (1) сигнализации к виртуальному функциональному компоненту 212'''. Виртуальный функциональный компонент 212''' пересылает принятое сообщение о событии к приложению 224 межплатформенной связи через функцию 214' межплатформенного программного обеспечения. Этот процесс указан как этапы (2) и (3) сигнализации на фиг.11.

Приложение 224 межплатформенной связи преобразует сообщение о событии в сообщение запроса, которое может быть интерпретировано IP модулем 212'. Соответствующее сообщение запроса затем пересылается, через функцию 226 межплатформенного программного обеспечения, на этапах (4) и (5) сигнализации к IP модулю 212'. Это сообщение запроса заменяет соответствующее сообщение о событии, которое было бы принято IP модулем 212', если бы NS модуль 210 был расположен вместе с IP модулем 212' на UMTS платформе 222.

Следует отметить, что сценарии сигнализации, обсужденные выше, конечно, могут быть расширены, и что, конечно, могут быть предложены и другие сценарии сигнализации. Например, понятия сигнализации, обсужденные выше в контексте с сообщениями о событиях и сообщениями запроса, обмениваемыми между удаленно расположенными функциональными компонентами, могут быть также воплощены для реализации внутренней сигнализации NAT или RAT хэндовера между двумя платформами сетевого доступа, такими как LTE и UMTS платформы, проиллюстрированные на чертежах. Кроме того, межплатформенные сообщения управления, относящиеся, например, к управлению системой, управлению радиосвязью или управлению блокировкой SIM, также могли бы быть реализованы. Эта сигнализация может, таким образом, в частности, но не исключительно, иметь отношение к сообщениям, связанным с сетевым доступом. Такие сообщения могут также включать в себя обмен модемными командами, такими как АТ команды, между двумя платформами сетевого доступа.

Сигнализация от одной платформы сетевого доступа к другой, возможно, может быть запущена посредством функциональности обратного вызова, обсужденной выше в контексте с DFM механизмом, показанным на фиг.6. Для того, чтобы, например, запустить генерацию события получения L1 измерения от RAT, реализованной на LTE платформенном CPU 202 по фиг.6, UMTS платформенный CPU 220 сначала должен уведомить (через соответствующую функцию межплатформенного программного обеспечения) LTE платформенный CPU 202 о том, что со стороны LTE платформы запрашивается L1 измерение. Если соответствующее L1 измерение, наконец, принято, то LTE платформенный CPU 202 запускает UMTS платформенный CPU 220 посредством соответствующей функции обратного вызова для переноса результатов измерения к UMTS платформенному CPU 202. В этом отношении могут быть реализованы потоки сигнализации, подобные иллюстрированным на фиг.13 и 14.

Можно предусмотреть в вышеприведенных вариантах осуществления, что одна единая стандартная платформенная система (такая как LTE платформенная система, описанная выше) скомбинирована с одной из множества различных других платформенных систем (таких как одна из нескольких UMTS платформенных систем). В таком случае может оказаться, что каждая из этих других платформенных систем нуждается в конкретной адаптации к функциям межплатформенного программного обеспечения, обеспеченным стандартной платформенной системой, и в таком случае сменные модули, обеспеченные на этом приложении или уровне межплатформенного программного обеспечения, могут использоваться для реализации необходимых адаптаций. Соответствующий дополнительный модуль может быть также перенесен к «удаленной» функции межплатформенного программного обеспечения с использованием, например, DFM механизма, иллюстрированного на фиг.6.

В случаях, в которых платформенная система, которая должна быть скомбинирована со стандартной платформенной системой, имеющей экспортную функциональность в отношении этой функции межплатформенного программного обеспечения, не поддерживает какие-либо из стандартов открытого интерфейса, таких как USB или UART, такой открытый интерфейс может быть заменен оригинальным интерфейсом, получающим доступ к общему ЗУПВ (RAM), расположенному между этими двумя платформенными системами.

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

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

Использование общепринятых и обычно используемых стандартов интерфейсов, таких как USB и UART, для подключения одной платформы сетевого доступа к другой платформе сетевого доступа облегчает адаптацию конкретной платформенной системы сетевого доступа к платформенным системам сетевого доступа и прикладным платформам различных производителей. Адаптация конкретной платформенной системы сетевого доступа к платформенной системе стороннего разработчика дополнительно облегчается посредством формирования интерфейсов и протоколов межплатформенной связи. Кроме того, удаленное управление индивидуальными платформенными системами сетевого доступа возможно, так как любой вызывающий функциональный компонент необязательно нуждается в совместном расположении с вызываемым функциональным компонентом на одной и той же платформенной системе сетевого доступа или на одном и том же устройстве. Этот подход также позволяет осуществить введение «бедных» (по содержанию) платформенных систем, которые подключаются к другим платформенным системам, если конкретные функции, не доступные локально, нуждаются в реализации.

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


СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
СПОСОБ СВЯЗИ МЕЖДУ ПЛАТФОРМАМИ
Источник поступления информации: Роспатент

Показаны записи 1-10 из 298.
27.01.2013
№216.012.2172

Способы и устройства в системе беспроводной связи

Изобретение относится к беспроводной связи, а именно к способам и устройствам автономных повторных передач HARQ. Техническим результатом является уменьшение числа требуемых повторных передач и уменьшение задержки предоставления сетевых услуг. Технический результат достигается тем, что способ...
Тип: Изобретение
Номер охранного документа: 0002474063
Дата охранного документа: 27.01.2013
10.02.2013
№216.012.24f3

Способ и устройство в сети радиодоступа

Изобретение относится к беспроводной связи. Техническим результатом является возможность легкого объединения повторителей включения/выключения в сети радиодоступа и минимизированной сигнализации для выбора повторителя UE. Этого достигают с помощью решения, в котором RBS работают в режиме...
Тип: Изобретение
Номер охранного документа: 0002474961
Дата охранного документа: 10.02.2013
27.02.2013
№216.012.2cc7

Устройства и способы подстройки частоты в синтезаторе частот с множеством выходов

Изобретение относится к области связи и может использоваться для управления точными источниками частоты в сотовых телефонах или других устройствах связи. Достигаемый технический результат - генерация из одного опорного тактового сигнала, по меньшей мере, двух тактовых сигналов для отдельных...
Тип: Изобретение
Номер охранного документа: 0002476990
Дата охранного документа: 27.02.2013
10.05.2013
№216.012.3f35

Идентификация процедуры ранжирования улучшенного беспроводного терминала

Изобретение относится к системам связи. Технический результат заключается в обеспечении согласования назначения ресурсов и возможностей терминала. Сеть связи содержит базовую станцию и беспроводной терминал, который взаимодействует по радиоинтерфейсу с базовой станцией. Базовая станция...
Тип: Изобретение
Номер охранного документа: 0002481748
Дата охранного документа: 10.05.2013
20.05.2013
№216.012.4291

Способ и устройство управления ресурсами передачи в процессах автоматических запросов на повторную передачу

Изобретение относится к системам связи. Технический результат заключается в оптимизации пропускной способности линии связи. Способ управления ресурсами передачи для передачи и повторной передачи пакетов множества процессов автоматических запросов на повторную передачу содержит выделение, для...
Тип: Изобретение
Номер охранного документа: 0002482611
Дата охранного документа: 20.05.2013
10.06.2013
№216.012.4a3a

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

Изобретение относится к технике беспроводной связи и может быть использовано для обработки сигналов связи, использующих последовательное вычитание помех. Способ обработки составного сигнала связи, содержащего два или более одновременно принятых представляющих интерес сигнала, содержит...
Тип: Изобретение
Номер охранного документа: 0002484582
Дата охранного документа: 10.06.2013
20.09.2013
№216.012.6d65

Повышение надежности протокола гибридного автоматического запроса на повторную передачу данных

Заявленное изобретение относится к протоколам передачи данных для передачи данных по совместно используемому нисходящему каналу связи. Технический результат состоит в уменьшении вероятности обнаружения ложного АСК, когда никакой сигнал ACK/NACK не передается терминалом пользователя. Для этого...
Тип: Изобретение
Номер охранного документа: 0002493656
Дата охранного документа: 20.09.2013
20.09.2013
№216.012.6d67

Способ и устройство для осуществления связи по радиоканалу

Изобретение относится к способам и устройствам связи в сети связи, в частности, предназначенным для передачи/приема данных по радиоканалу. Техническим результатом является увеличение количества различных преамбул, подлежащих использованию в процессе произвольного доступа. Указанный технический...
Тип: Изобретение
Номер охранного документа: 0002493658
Дата охранного документа: 20.09.2013
20.10.2013
№216.012.776a

Способ и устройство достоверного определения весовых коэффициентов в системе cdma с помехами

Изобретение относится к системам множественного доступа с кодовым разделением (CDMA) и к гибкому масштабированию при обработке сигналов связи и предназначено для повышения точности гибкого масштабирования за счет использования информации о распределении по времени помех. Принятый представляющий...
Тип: Изобретение
Номер охранного документа: 0002496230
Дата охранного документа: 20.10.2013
10.12.2013
№216.012.8aa1

Выбор настроек повторной передачи для harq в сетях wcdma и lte

Изобретение относится к протоколам повторной передачи, а более конкретно к выбору параметров повторной передачи для операций гибридного автоматического запроса на повторную передачу в системах беспроводной связи. Повышение производительности HARQ-операции достигается посредством...
Тип: Изобретение
Номер охранного документа: 0002501171
Дата охранного документа: 10.12.2013
Показаны записи 1-10 из 268.
27.01.2013
№216.012.2172

Способы и устройства в системе беспроводной связи

Изобретение относится к беспроводной связи, а именно к способам и устройствам автономных повторных передач HARQ. Техническим результатом является уменьшение числа требуемых повторных передач и уменьшение задержки предоставления сетевых услуг. Технический результат достигается тем, что способ...
Тип: Изобретение
Номер охранного документа: 0002474063
Дата охранного документа: 27.01.2013
10.02.2013
№216.012.24f3

Способ и устройство в сети радиодоступа

Изобретение относится к беспроводной связи. Техническим результатом является возможность легкого объединения повторителей включения/выключения в сети радиодоступа и минимизированной сигнализации для выбора повторителя UE. Этого достигают с помощью решения, в котором RBS работают в режиме...
Тип: Изобретение
Номер охранного документа: 0002474961
Дата охранного документа: 10.02.2013
27.02.2013
№216.012.2cc7

Устройства и способы подстройки частоты в синтезаторе частот с множеством выходов

Изобретение относится к области связи и может использоваться для управления точными источниками частоты в сотовых телефонах или других устройствах связи. Достигаемый технический результат - генерация из одного опорного тактового сигнала, по меньшей мере, двух тактовых сигналов для отдельных...
Тип: Изобретение
Номер охранного документа: 0002476990
Дата охранного документа: 27.02.2013
10.05.2013
№216.012.3f35

Идентификация процедуры ранжирования улучшенного беспроводного терминала

Изобретение относится к системам связи. Технический результат заключается в обеспечении согласования назначения ресурсов и возможностей терминала. Сеть связи содержит базовую станцию и беспроводной терминал, который взаимодействует по радиоинтерфейсу с базовой станцией. Базовая станция...
Тип: Изобретение
Номер охранного документа: 0002481748
Дата охранного документа: 10.05.2013
20.05.2013
№216.012.4291

Способ и устройство управления ресурсами передачи в процессах автоматических запросов на повторную передачу

Изобретение относится к системам связи. Технический результат заключается в оптимизации пропускной способности линии связи. Способ управления ресурсами передачи для передачи и повторной передачи пакетов множества процессов автоматических запросов на повторную передачу содержит выделение, для...
Тип: Изобретение
Номер охранного документа: 0002482611
Дата охранного документа: 20.05.2013
27.05.2013
№216.012.45d2

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

Изобретение относится к технике беспроводной связи и может быть использовано для уменьшения влияния изменения помех во времени. Сетевые базовые станции уменьшают временные изменения в помехе, воспринимаемой мобильными станциями, действующими внутри сети (60), замедляя скорость, с которой они...
Тип: Изобретение
Номер охранного документа: 0002483451
Дата охранного документа: 27.05.2013
10.06.2013
№216.012.4a3a

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

Изобретение относится к технике беспроводной связи и может быть использовано для обработки сигналов связи, использующих последовательное вычитание помех. Способ обработки составного сигнала связи, содержащего два или более одновременно принятых представляющих интерес сигнала, содержит...
Тип: Изобретение
Номер охранного документа: 0002484582
Дата охранного документа: 10.06.2013
27.07.2013
№216.012.5b39

Способы и устройства для уведомления о чрезвычайных ситуациях

Изобретение относится к области радиосвязи. Техническим результатом является достижение сообщения о чрезвычайной ситуации пользовательского оборудования эффективным и надежным образом. Упомянутый технический результат достигается тем, что первое устройство связи принимает уведомление о...
Тип: Изобретение
Номер охранного документа: 0002488974
Дата охранного документа: 27.07.2013
20.09.2013
№216.012.6d65

Повышение надежности протокола гибридного автоматического запроса на повторную передачу данных

Заявленное изобретение относится к протоколам передачи данных для передачи данных по совместно используемому нисходящему каналу связи. Технический результат состоит в уменьшении вероятности обнаружения ложного АСК, когда никакой сигнал ACK/NACK не передается терминалом пользователя. Для этого...
Тип: Изобретение
Номер охранного документа: 0002493656
Дата охранного документа: 20.09.2013
20.09.2013
№216.012.6d67

Способ и устройство для осуществления связи по радиоканалу

Изобретение относится к способам и устройствам связи в сети связи, в частности, предназначенным для передачи/приема данных по радиоканалу. Техническим результатом является увеличение количества различных преамбул, подлежащих использованию в процессе произвольного доступа. Указанный технический...
Тип: Изобретение
Номер охранного документа: 0002493658
Дата охранного документа: 20.09.2013
+ добавить свой РИД