Способ связи между платформами

Способ связи между платформами

Иллюстрации

Показать все

Реферат

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

Настоящее изобретение, в общем, относится к технологиям сетевого доступа (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 межплатф