Волосатова Т.М., Беломойцев Д.Е.

 

1. Введение

В течение всего времени существования расчетных задач для решения многих из них не хватало вычислительных мощностей. Это было причиной постоянного процесса совершенствования техники. Во второй половине прошлого века были успешно проведены десятки экспериментов по объединению мощностей отдельных компьютеров для решения общей задачи. Схемы были различны - от непосредственного соединения процессорных устройств в рамках кластеров до создания распределенных систем [14].

На современном уровне развития вычислительной техники, как правило, персональные компьютеры или рабочие станции объединяются в различного рода сети [17]. В полной мере это относится и к мобильным устройствам. В настоящее время при выборе технического оснащения одним из решающих факторов является степень мобильности. Потребность в доступе к большим или распределенным в пространстве массивам информации определяет необходимость подключения к сетевым магистралям. При этом чрезвычайно актуальным является аспект мобильности при доступе к сети. Само понятие «мобильный» предполагает, что прибор способен выполнять свои функции, находясь в движении. Единственной возможностью взаимодействовать с другими устройствами и при этом не быть ограниченным в подвижности является использование беспроводных технологий связи.

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

В этом случае уже разработанные закономерности и модели следует адаптировать к существенно отличной среде функционирования [6]. Различия присутствуют практически во всем:

1.         подвижность элементов системы в пространстве становится гораздо выше;

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

3.         вычислительная мощность отдельных элементов системы намного ниже, чем у ПК;

4.         ресурс мобильных устройств зачастую зависит от заряда аккумулятора.

Рассматривая понятие мобильности, происходящее от латинского «mobilis» – подвижный, готовый к действию, можно прийти к выводу, что связанное с ним понятие мобильного устройства предполагает чрезвычайно широкий спектр представителей своего модельного ряда. В него входят практически все переносимые компьютеры – начиная с портативных, ноутбуков, КПК (Карманных Персональных Компьютеров) и заканчивая некоторыми промышленными моделями. Также в этом ряду находятся мобильные телефоны, цифровые фотоаппараты и камеры. На примере последних отчетливо заметно, что в последние несколько лет наметилась тенденция к интеграции прямой функциональности этих устройств с дополнительной, как то долговременным хранением информации и ассортиментом интерфейсов коммуникации. То есть в современных мобильных устройствах имеется достаточно большая емкость для хранения данных, а также возможность соединяться с другими телефонами, фотоаппаратами или компьютерами как по кабельным, так и по беспроводным соединениям. Таким образом, устройство с высокой степенью интеграции функциональности представляет собой практически универсальный инструмент в руках владельца. При наличии средств для установления соединений с другими такими же «инструментами» появляется возможность использовать их функции в своих целях. Следовательно, способность к установлению локальных соединений становится почти такой же по значимости, как и первоочередная функциональность устройства.

Одним из способов обмена данными между мобильными устройствами в рамках локальных соединений является создание этими устройствами беспроводных сетей, так называемых пикосетей (piconet). Пикосети – это объединение мобильных устройств в различного рода сети беспроводным путем, благодаря использованию программно-аппаратных структурных элементов: инфракрасных или радио-соединений, например, Bluetooth, WiFi и т.д. В подобные сети чаще всего входят от 2 до 8 устройств, одно из которых (master) синхронизирует работу остальных (slave) устройств.

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

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

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

2. Технологии построения беспроводных соединений мобильных устройств

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

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

Возможны несколько способов беспроводной передачи информации между мобильными устройствами [20] – инфракрасное соединение и радиосвязь (локальные радио-каналы и передача данных в рамках сотовых телекоммуникационных сетей). Обмен информацией по инфракрасным каналам не обеспечивает приемлемой степени мобильности и пропускной способности, поэтому имеет смыcл рассматривать технологии локальной беспроводной связи (например, Bluetooth и WiFi), а также технологию пакетной передачи данных в рамках сотовой сети GPRS.

2.1. Технология WiFi

Радиосвязь уже достаточно давно стала неотъемлемой частью аппаратной базы информационных технологий. Существует технология Radio Ethernet, осуществляющая беспроводную коммуникацию рабочих станций. В период с 1990 по 1997 годы в результате работы одной из рабочих групп IEEE была создана первая спецификация стандарта беспроводных локальных соединений 802.11.

IEEE 802.11 стал базовым стандартом, определившим основные протоколы, необходимые для организации беспроводных локальных сетей (Wireless Local Area Network - WLAN), а также явился первым стандартом для продуктов WLAN от независимой международной организации, разрабатывающей большинство стандартов для проводных сетей.

В стандарте 802.11 предусмотрено два основных типа архитектуры сетей: Ad-hoc и Infrastructure Mode. Простейшим из них является вариант Ad-hoc, который называют также IBSS (Independent Basic Service Set) или режим Peer-to-Peer ("точка-точка"). В этом режиме связь устанавливается непосредственно между рабочими станциями пользователей по принципу "каждый с каждым" и создание какой-либо общей сетевой инфраструктуры не требуется.

Но значительно большими возможностями обладают сети, работающие в режиме Infrastructure Mode, основу которых составляет сотовая архитектура, подобная той, что используется в мобильной связи. При этом такие сети могут состоять как из одной, так и из множества ячеек. Каждая отдельная сота беспроводной сети управляется своей базовой станцией, называемой точкой доступа (Access Point), которая взаимодействует с находящимися в пределах ее радиуса действия пользовательскими устройствами. В этом режиме устройства пользователей напрямую друг с другом не связываются, а действуют через точку доступа. Сами же точки доступа соединяются между собой либо с помощью кабельной сети, либо по специальным радиоканалам и могут иметь связь с другими сетями или выход в Интернет.

Теоретически, к каждой точке доступа может быть подключено до 255 пользователей (это количество продиктовано ограничениями IP-протокола [22]), однако на практике данное число оказывается существенно меньше и реально составляет 20-50 пользователей.

Для обеспечения возможности совместной работы в сети большого количества пользовательских устройств без взаимных помех, стандартом определен специальный механизм их перехода в режим передачи с предварительным уведомлением о намерении посылки данных, получивший наименование Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) - множественный доступ с обнаружением несущей и предотвращением коллизий.

Для повышения надежности передачи информации, а также создания условий для функционирования в единой полосе частот устройств самого различного назначения, с минимальными помехами между ними, в стандарте 802.11 предусмотрено использование радиоканалов с широкополосными сигналами, формируемыми по одной из двух технологий - псевдослучайной скачкообразной перестройки рабочей частоты (Frequency Hopping Spread Spectrum - FHSS) или так называемого метода прямой последовательности (Direct Sequence Spread Spectrum - DSSS).

Идея способа радиопередачи со скачкообразными перестройками частоты проста и не требует особых пояснений, а сам метод был широко опробован еще во время Второй Мировой войны при работе разведчиков на территориях противника. Передача радиограмм не целиком, а отдельными частями по очереди на разных, заранее оговоренных, частотах затрудняла как их перехват, так и забивание помехами. Эти же свойства используются и в современной технологии FHSS, где данные посылаются короткими пакетами с переходом с одной частоты на другую в соответствии с заранее заданными правилами. Для этого стандартом 802.11 предусмотрено формирование в пределах рабочего диапазона частот 79 каналов с шириной полосы каждого в 1 МГц. При обмене информацией передатчики и приемники взаимодействующих устройств периодически (с интервалами в 20-400 мс) и синхронно друг с другом переключается на новый канал. При этом алгоритм изменения частот известен обоим участникам связи, а разные пары используют различные последовательности переключений частот. Всего в стандарте предусмотрено 22 варианта таких схем переходов.

Сущность технологии DSSS заключена в использовании другого эффекта. Здесь каждый бит передаваемой информации преобразуется, по заранее определенному алгоритму, в последовательность из нескольких более коротких элементов ("чипов" - chip), образующих так называемый микрокадр. При приеме полученная последовательность элементов декодируется с использованием того же алгоритма. Если в процессе передачи один или даже несколько элементов микрокадра окажутся искажены, то исходные данные во многих случаях все же могут быть правильно восстановлены по оставшимся принятым элементам. Разные пары "приемник-передатчик" в системе используют разные алгоритмы кодировки-декодировки, что обеспечивает возможность их одновременной работы без заметных взаимных помех, так как чужие кодовые последовательности будут восприниматься приемником примерно как небольшой случайный шум.

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

В стандарте IEEE 802.11 при передаче данных на скорости 1 Мбит/с используется двоичная относительная фазовая модуляция (DBPSK). При этом сам информационный единичный бит для расширения спектра сигнала по технологии DSSS передается 11-чиповой последовательностью Баркера, а нулевой бит - инверсной последовательностью Баркера.

Информационная скорость 1 Мбит/с является обязательной в стандарте IEEE 802.11 (basic access rate), но опционально возможна передача и на скорости 2 Мбит/с (enhanced access rate). Для передачи данных на такой скорости также используется относительная фазовая модуляция, но уже квадратурная (DQPSK). Это позволяет в два раза повысить информационную скорость передачи. При этом ширина самого спектра остается прежней - 22 МГц.

Спецификация пакетирования данных, предусмотренная стандартом, предписывает разбивку данных на пакеты, снабженные контрольной и адресной информацией длиной в 30 байт, блока данных длиной до 2048 байт и 4-байтного CRC-блока (контрольной суммы), что гарантирует обнаружение сбойных кадров при приеме. Стандарт рекомендует использовать пакеты длиной 1500 или 2048 байт.

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

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

IEEE 802.11а

В 1999 году был принят стандарт IEEE 802.11а. Он ориентирован на работу в ISM диапазоне 5 ГГц и способен обеспечить скорость передачи данных до 54 Мбит/с (с вариантами ее увеличения до 100 Мбит/с и более). В 802.11a применена технология построения радиоканала на основе мультиплексирования с ортогональным разделением частот - Orthogonal Frequency Division Multiplexion (OFDM), к этому моменту уже хорошо проверенная на практике в европейских системах цифрового радиовещания DAB и телевидения DVB. Ее суть заключается в том, что передача информации осуществляется не по одному высокоскоростному каналу, а с помощью ряда независимых радиосигналов. Такое разделение посылаемой информации по нескольким "несущим" частотам приводит к возможности снижения скорости передачи на каждой из них, что в свою очередь обеспечивает большую помехозащищенность связи при достижении общей высокой пропускной способности.

Диапазон состоит из двух частотных полос общей шириной 300 МГц. Первая полоса 5,15-5,35 ГГц, вторая — 5,725-5,825 ГГц. При этом первая полоса разделена на две 100-МГц части. Таким образом, для передачи используется три 100-МГц не перекрывающихся канала, каждый из которых предполагает различные ограничения на мощность: 50 мВт в «нижнем», 250 мВт в «среднем» и до 1 Вт в «верхнем». В России оборудование этого стандарта использовать не разрешено, поскольку в нем работает оборудование государственных служб. Стандарт 802.11а предписывает переход на метод кодированного ортогонального частотного мультиплексирования (COFDM, Coded Orthogonal Frequency Division Multiplexing), скорость передачи данных достигает 54 Мбит/с. Работа с такой скоростью возможна благодаря разбиению одного «быстрого» 20-МГц канала на 52 «медленных» 300-кГц несущих. Существующие спецификации позволяют одновременно работать только одному устройству (использующему все 52 несущих). В стандарте определены три обязательные скорости передачи данных (6, 12 и 24 Мбит/с) и пять дополнительных (9, 18, 24, 48 и 54 Мбит/с). Имеется возможность одновременного использования двух каналов; скорость при этом удваивается.

Вследствие сложности производства более высокочастотного оборудования, реальный выпуск устройств стандарта 802.11a начался только в конце 2001 г., из-за чего они пока получили существенно меньшее распространение.

В США частотный диапазон именуют диапазоном нелицензионной национальной информационной инфраструктуры (Unlicensed National Information Infrastructure, UNII).

Таблица 2.1. Частотный диапазон стандарта IEEE 802.11a

 

В соответствии с правилами FCC частотный диапазон UNII разбит на три 100-мегагерцевых поддиапазона, различающихся ограничениями по максимальной мощности излучения. Низший диапазон (от 5,15 до 5,25 ГГц) предусматривает мощность всего 50 мВт, средний диапазон (от 5,25 до 5,35 ГГц) - 250 мВт, а верхний диапазон (от 5,725 до 5,825 ГГц) - 1 Вт. Использование трёх частотных поддиапазонов с общей шириной 300 МГц делает стандарт 802.11а самым, так сказать, широкополосным из семейства стандартов 802.11 и позволяет разбить весь частотный диапазон на 12 каналов, каждый из которых имеет ширину 20 МГц, восемь из которых лежат в 200-мегагерцевом диапазоне от 5,15 до 5,35 ГГц, а остальные четыре канала - в 100-мегагерцевом диапазоне от 5,725 до 5,825 ГГц. При этом четыре верхних частотных каналов, предусматривающие наибольшую мощность передачи, используются преимущественно для передачи сигналов вне помещений.

Предусмотренная протоколом 802.11а ширина канала 20 МГц вполне достаточна для организации высокоскоростной передачи. Использование же частот свыше 5 ГГц и ограничение мощности передачи приводят к возникновению ряда проблем при попытке организовать высокоскоростную передачу данных, и это необходимо учитывать при выборе метода кодирования данных.

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

,

где: X - коэффициент ослабления, равный 20 для открытого пространства, d - расстояние от точки передачи, f - частота сигнала, с - скорость света.

Из данной формулы непосредственно вытекает, что с увеличением частоты передаваемого сигнала увеличивается и его затухание. Так, при распространении сигнала в открытом пространстве с частотой 2,4 ГГц он ослабевает на 60 дБ при удалении от источника на 10 м. Если же частота равна 5 ГГц, ослабевание сигнала при удалении на 10 м составит уже 66 дБ. Учитывая, что правила FCC диктуют использование существенно меньшей мощности излучения в нижних поддиапазонах UNII, чем в диапазоне ISM 2,4 ГГц, становится понятно, что использование более высоких частот в протоколе 802.11а приводит к несколько меньшему радиусу действия сети.

IEEE 802.11b

Одним из наиболее распространенных на сегодняшний день является стандарт 802.11b, более известный по его другому наименованию - Wi-Fi (Wireless Fidelity) - присвоенному ему Ассоциацией Wireless Ethernet Compatibility Alliance (WECA). Он был принят в 1999 году, и именно его появление привело к нынешнему широкому распространению WLAN для организации локальных сетей и доступа в Интернет.

Для работы сетей Wi-Fi стандартом предусмотрено использование частотного диапазона от 2,4 до 2,4835 ГГц, который во многих странах предназначен для безлицензионного использования в промышленности, науке и медицине (диапазон ISM - Industrial, Scientific, Medical). В России данный диапазон выделен для тех же целей, но его использование требует получения разрешения от Государственного комитета по радиочастотам и Главгоссвязьнадзора РФ.

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

По сравнению с базовым стандартом, в котором предусматривалась передача данных на скоростях 1 и 2 Мбит/с, в стандарте 802.11b обязательными являются также скорости 5,5 и 11 Мбит/с. Для работы на таких скоростях используется уже несколько иной способ расширения спектра - на основе кодирования с использованием комплементарных кодов (Complementary Code Keying, CCK).

Если говорить в общих чертах, то использование CCK-кодов позволяет кодировать 8 бит на один символ при скорости 11 Мбит/с и 4 бита на символ при скорости 5,5 Мбит/с. В стандарте IEEE 802.11b используются комплексные комплементарные последовательности, содержащие элементы с четырьмя различными фазами. При этом сами кодовые последовательности являются 8-чиповыми, и при скорости передачи 11 Мбит/с кодирование 8 бит на символ соответствует символьной скорости 1,375 мегасимволов в секунду (11/8 = 1,375). Аналогичная символьная скорость используется и при скорости передачи 5,5 Мбит/с, так как при такой скорости в одном символе кодируется только 4 бита.

Сейчас оборудование стандарта 802.11b выпускается множеством компаний, а совместимость изделий различных производителей гарантируется сертификатами Ассоциации WECA, членами которой являются более 80 компаний, в том числе такие известные производители, как 3Com, AMD, Apple, Avaya Communication, Cisco Systems, Compaq, Dell, Fujitsu, IBM, Intel, Siemens, Sony и др.

IEEE 802.11g

Этот стандарт принят в середине 2003 года; он создавался как развитие стандарта 802.11b. В нем используется тот же частотный диапазон 2,4 ГГц, но по технологии OFDM, что обеспечило достижение скорости передачи данных, такой же, как и в 802.11а - до 54 Мбит/с. Однако, несмотря на различие используемых технологий, оборудование стандарта 802.11g выпускается совместимым с его предшественником, т. е. пользователи, имеющие платы 802.11b, при попадании в зоны действия 802.11g по-прежнему могут пользоваться услугами беспроводного доступа, но, правда, только на "своей" скорости - до 11 Мбит/с. Аналогично обстоит дело и с устройствами стандарта 802.11g в сетях 802.11b.

Мощность устройств данного стандарта составляет 10-100 мВт. Обратная совместимость с 802.11b достигается благодаря выбору частотного диапазона 2,4 ГГц и одинаковой схеме модуляции — ССК-кодированию. Стоит отметить, что 802.11g реализует новый физический уровень для управления доступом к среде передачи 802.11 MAC, известный как расширение физического уровня (extended rate PHY, ERP). При этом OFDM в качестве обязательной схемы модуляции применяется для скоростей 6, 12 и 24 Мбит/с (обязательные) и 18, 36, 48 и 54 Мбит/с (дополнительные). ERP содержит также схемы модуляции 802.11b, в том числе ССК для 5,5 и 11 Мбит/с и кодирование Баркера для 1 и 2 Мбит/с.

IEEE 802.11е

Стандарт 802.11e должен решить вопросы обеспечения качества сервиса (QoS), весьма актуальные при передаче аудио- и видеоинформации и особенно потокового трафика. Для обеспечения различных уровней QoS в спецификациях 802.11e предусматривается использование протокола резервирования ресурсов (Resource Reservation Protocol - RSVP) и механизма приоритезации очередей. Кроме этого, для разных видов потоков данных предусмотрена возможность использования разных методов передачи. Например, для пересылки чувствительного к задержкам видеопотока, вместо механизма повторной передачи пакетов, может задействоваться метод упреждающей коррекции ошибок.

Организация микросотовых сетей

Семейство стандартов IEEE 802.11 (в том числе с расширением IEEE 802.11b) позволяет организовать беспроводные сети с несколькими точками доступа, аналогичные по принципу работы сетям сотовой связи. Это происходит следующим образом [13].

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

Имееются три частотных канала, которые можно одновременно использовать в одном и том же месте. Соответственно точки доступа, каждая из которых настроена на один из этих трех каналов, можно разместить таким образом, что соседние точки доступа будут работать на разных частотах. Однако при этом иногда возникает паразитное взаимное влияние между точками доступа, расположенными не в соседних сотах, а через соту. Эта проблема может быть решена, если использовать то обстоятельство, что на самом деле выделено 14 каналов и размещение в частотном спектре трех каналов, а также защитных интервалов между ними можно варьировать. Каналы, на которых работают точки доступа в сотах, не являющихся соседними, могут быть близки по частоте, но точно не совпадать. Если для точек доступа, расположенных в соседних сотах, такая ситуация приведет к взаимным помехам, то в точках доступа, расположенных через соту, каналы, полосы которых соседствуют друг с другом или даже частично пересекаются, но полностью не совпадают, не будут оказывать практически никакого взаимного влияния.

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

2.2. Технология WiMAX

Основанная на стандарте беспроводной связи IEEE 802.16-2004 технология WiMAX (Worldwide Interoperability for Microwave Access) на сегодняшний день развивается стремительными темпами и, вероятно, будет играть ключевую роль в создании т.н. MAN (metropolitan area networks) в самом ближайшем будущем [10].

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

Рис.2.1. Топология сети WiMAX

Интерфейс мобильной беспроводной связи WiMAX основывается на использовании модуляции OFDMA (Orthogonal Frequency Division Multiple Access), в то время как технология 802.16e применяет масштабируемую модуляцию OFDMA (SOFDMA) с целью поддержки изменяемой ширины канала – от 1.25 до 20 МГц. В версии Release-1 Mobile WiMAX работа идет с использованием каналов пропускной способностью 5, 7, 8.75 и 10 МГц на лицензируемых частотах 2.3, 2.5 и 3.5 ГГц.

Использование антенных технологий MIMO, гибкой схемы работы с каналами, а также ACM (Advanced Coding and Modulation) позволяет добиться скорости приема данных 63 МБит\c, а передачи – 28 МБит\c на сектор в канале 10 МГц.

Фундаментальной особенносью архитектуры МАС-уровня (Media Access Control) 802.16 является QoS (Quality of Service), который может быть ориентирован на соединение или на сервис.Алгоритмы и схемы распределения каналов обеспечивают гибкий механизм оптимального распределения ресурсов времени, частот и пространства для беспроводного соединения.

Зона распространения радиосвязи c применением технологии WiMAX составляет до 50 км. Таким образом данный способ передачи данных представляет собой потенциально удобную реализацию соединения «последней мили». В отличие от любой другой методики организации локальных беспроводных сетей, зона охвата которых в лучшем случае составляет десятки или сотни метров в приложении к одной точке доступа, WiMAX позволяет не только значительно увеличить расстояние между передатчиками, но и повысить мобильность соединения. Благодаря редакции стандарта 802.16e передатчику позволяется изменять свое положение в пространстве в определенных рамках, связывающих скорость перемещения и скорость обмена данными, не разрывая соединения.

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

 

2.3. Технология Bluetooth

Увеличение скорости обмена информацией способствовало развитию беспроводных систем связи на "домашнем" уровне. Персональные компьютеры и ноутбуки, сотовые телефоны, CD- и МР3-плееры, цифровые фото- и видеокамеры и масса других цифровых устройств, часто подсоединяемых друг к другу и к стационарным компьютерам, создали проблему их связи.

Кабель стал неудобен - подключаться надо часто, размеры самого кабеля с разъёмами едва не больше собственно подключаемого устройства. На этом фоне резко возросла актуальность беспроводных локальных технологий WLAN (Wireless Local Area Networking), обеспечивающих бесконтактное подключение устройства к диску ведущего компьютера.

В результате была предложена и стала быстро развиваться система беспроводной связи Bluetooth. В спектре радиочастот ей отведено 79 каналов в полосе 37 МГц (примерно 2 МГц каждый) в диапазоне 2,4465-2,4835 ГГц [16].

Суть стандарта Bluetooth в оснащении электронных устройств приёмопередатчиками, работающими на частоте 2,45 ГГц, имеющими радиус действия до 10 м и скорость передачи информации до 1 Мбит/с. Возможности применения данных устройств поистине безграничны - беспроводные наушники, мышки, клавиатуры, соединение мобильных телефонов и ноутбуков, обмен информацией между карманными компьютерами.

Технология Bluetooth работает в разрешённой полосе 2,45 ГГц (полоса промышленного, научного и медицинского применения ISM - Industry, Science, Medicine), что позволяет свободно использовать устройства Bluetooth во всём мире. Технология использует скачкообразную перестройку частоты (1600 скачков/с) с расширением спектра. При работе передатчик перескакивает с одной рабочей частоты на другую по псевдослучайному алгоритму. Для разделения приёмного и передающего каналов используется временное разделение. Поддерживается синхронная и асинхронная передача данных. Временные интервалы синхронизированы для передачи пакетов, каждый из которых передаётся на своей частоте радиосигнала.

Потребление мощности устройств Bluetooth должно быть в пределах 0,1 Вт. Каждое устройство имеет уникальный 48-битный сетевой адрес, совместимый с форматом стандарта локальных сетей IEEE 802.

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

Кроме того, в устройствах Bluetooth применяют интегральные схемы, используемые в других приложениях, поскольку СВЧ-диапазон 2 ГГц освоен достаточно хорошо, а заложенные в Bluetooth технические решения сами по себе особой новизны не содержат. В самом деле, схема модуляции - широко распространена, технология расширения спектра методом частотных скачков хорошо отработана, мощность мала.

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

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

Разработку Bluetooth начала компания ERICSSON ещё в 1994 году. Первоначальной целью было получение нового радиоинтерфейса с низким уровнем энергопотребления и невысокой стоимостью, который позволил бы устанавливать связь между сотовыми телефонами и беспроводными гарнитурами. Кроме того, согласно концепции ERICSSON, новый интерфейс предназначался для передачи данных и речевых сообщений, причём из любой точки мира. Для обеспечения более широкой поддержки молодой технологии в таких секторах рынка, как настольные системы, карманные компьютеры и мобильные телефоны, ERICSSON в феврале 1998 года организовала консорциум по разработке и продвижению новой технологии под названием Bluetooth SIG (Special Interest Group). Ныне в него входит более 2000 различных фирм, в том числе такие крупные, как 3СOM, NOKIA, INTEL, NATIONAL SEMICONDUCTOR и др.

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

На примере Bluetooth-связи по типу "точка - точка" показано информационное взаимодействие двух хостов. Каждый Bluetooth-модуль содержит формирующую и приёмно-передающую аппаратуру, а также встроенное или "зашитое" программное обеспечение (Firmware). К последнему относится интерфейс хост-контроллера (HCI), менеджер связи (Link Manager), а также контроллер несущей частоты (Baseband).Связь модуля с хостом на физическом и канальном уровнях осуществляется с помощью шин USB, UART, PC Card и соответствующего встроенного ПО. К физическому уровню относится также радиолиния между модулями.

Модуль поддерживает приём - передачу данных и речевых сигналов. Связь между модулем и хост-контроллером производится с помощью высокоскоростного USB-интерфейса или UART/PCM-интерфейса. Когда используется USB-интерфейс, модуль является USB-ведомым прибором и поэтому не требует ресурсов персонального компьютера.

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

Технология Вluetooth предполагает два вида связи: синхронную - SCO (Synchronous Connection Oriented) и асинхронную - ACL (Аsynchronous Connectionless). Первый вид, SCO, рассчитан на установление симметричного соединения "точка - точка" и служит преимущественно для передачи речевых сообщений. Скорость передачи информации SCO равна 64 Кит/с. Второй, ACL, предназначен для пакетной передачи данных. Он поддерживает симметричные и асимметричные соединения типа "точка - много точек". Скорость передачи пакетной информации при ACL cоставляет порядка 721 Кбит/с. Пакеты данных имеют фиксированный формат. В начале блока находится 72-бит код доступа. Он может применяться, в частности, для синхронизации устройств. За ним следует 54-бит заголовок пакета, содержащий контрольную сумму пакета и информацию о его параметрах (например, о повторной передаче блока данных). Замыкает пакет область, непосредственно содержащая пересылаемую информацию. Размер этой области варьируется от 0 до 2745 бит.

Основополагающим принципом построения систем Bluetooth является использование метода расширения спектра при скачкообразном изменении частоты (FHSS - Frequency Hop Spread Spectrum). Весь выделенный для Bluetooth-радиосвязи частотный диапазон 2,402…2,480 ГГц разбит на N частотных каналов. Полоса каждого канала 1 МГц, разнос каналов - 140…175 кГц. Для кодирования пакетной информации используется частотная манипуляция.

Для США и Европы N = 79. Исключение составляют Испания и Франция, где для Bluetooth применяется 23 частотных канала. Смена каналов производится по псевдослучайному закону с частотой 1600 Гц. Постоянное чередование частот позволяет радиоинтерфейсу Bluetooth транслировать информацию по всему диапазону ISM и избежать воздействия помех со стороны устройств, работающих в этом же диапазоне. Если данный канал зашумлён, то система перейдёт на другой, и так будет происходить до тех пор, пока не обнаружится канал, свободный от помех.

Когда пара любых Bluetooth-устройств соединяется, они образуют пикосеть. Аппарат, инициирующий связь, является ведущим (host, master), а остальные - ведомыми (slaves). Обычно ведущим является тот модуль, который размещён в наиболее мощном устройстве, таком, как персональный компьютер или плата CPU мини-ЭВМ. Число модулей в беспроводном соединении не ограничивается, но в любой момент времени активны должны быть не больше восьми. Не существует разницы как в аппаратной, так и в программной части между ведущими и ведомыми устройствами. Любое из них может быть и тем и другим. Ведущее формирует беспроводное соединение (в каждой сети оно только одно) и полностью контролирует трафик. Ведомые могут отсылать сообщения только в интервале "ведомые - ведущему" после того, как к ним обратился в предшествующий слот "ведущий - ведомым". Если в этом интервале у ведущего нет никакой информации для отправки ведомым, то он передает пакет только с кодом доступа и заголовком. Если в сети оказывается более 8 устройств, то будет сформирована вторая пикосеть и так далее. Предусмотрена координация трафика и между сетями. Множество пикосетей, способных взаимодействовать друг с другом, формируют распределённую сеть (Scatternet).

Несмотря на FHSS, устройства Bluetooth не всегда могут исключить проблемы, связанные с воздействием помех в диапазоне 2,4 ГГц. Поэтому помимо FHSS используется специальное кодирование сигналов. Во-первых, кодирование трафика заметно повышает уровень защищённости связи. Во-вторых, кодирование позволяет с помощью специальных алгоритмов обнаруживать и корректировать ошибки передачи данных. Кроме того, чтобы быть уверенным в том, что устройства вступают в связь только с авторизованными на то устройствами, предусмотрена также встроенная процедура аутентификации. Этим пресекается несанкционированный доступ к данным.

 

2.4. Технология Bluetooth 2.0 – Enhanced Data Rate

Дополнение EDR (Enhanced Data Rate) к стандарту Bluetooth 2.0 было ратифицировано в ноябре 2004 года. В целом, данный стандарт определяет изменения способов модуляции и дополнительные типы пакетов данных, с помощью которых возможно достичь пиковой скорости передачи 3 Мбит/с (с реальной передачей 2.1 Мбит/с) [2].

Практически для любой технологии связи «быстрее» почти всегда означает «лучше» [9]. Однако в случае с EDR, выбор скорости 3 Мбит/с просто реализует желание большей скорости, хотя в настоящее время редкое приложение требует скорости более нынешних 1 Мбит/с (723 кбит/с) для версии 1.х.

Кроме этого, стандарт EDR значительно снижает потребление энергии устройствами Bluetooth. Так как её расход напрямую зависит от времени работы в активном состоянии, то снижение этого времени за счет более быстрой передачи приводит к снижению потребления (как минимум в два-три раза).

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

Стандартный пакет данных Bluetooth включает четыре секции: Access Code, Header, Payload и Inter-Packet Guard Band. В спецификации стандарта 1.2 все три секции передач используют алгоритм модуляции радио сигнала GFSK (Gaussian frequency-shift keying). Несущая частота колеблется в диапазоне +/-160 kHz для представления единиц и нулей, обозначающих биты символа. Скорость передачи 1Мсимвол/с в пиковом состоянии означает 1 Мбит/с. Однако, передача кроме собственно данных еще и сопроводительных кодов, заголовков пакета приводит к тому, что эффективная скорость передачи составляет 723 кбит/с.

В версии стандарта 2.0 EDR пакетами также используется модуляция GFSK для кодов доступа и заголовков. Однако для секции собственно данных применяется одна из двух других схем модуляции – обязательная и опциональная. Смена схемы требует включения небольшой охранной зоны и синхро-последовательности между секциями заголовка и данных.

Обязательная скорость передачи 2Х (2 Мбит/с) использует модуляцию п/4 DQPSK (differential quaternary phase-shift keying).  В отличие от GFSK этот алгоритм варьирует фазу несущей, а не частоту. «Четвертичный» означает, что для каждого символа возможны четыре положения фазы, позволяющие двум битам данных быть закодированными в один символ. Так как при этом скорость в символах остается неизменной, имеется двукратное ускорение скорости передачи в битах.

Алгоритм п/4-DQPSK дифференциальный, потому что именно положение фазы каждого символа относительно предыдущего положения определяет то, что кодируется по 2 бита.

Для скорости передачи 3Х (3Мбит/с) используется алгоритм модуляции 8DQPSK (8-phase differential quaternary phase-shift keying). Он сравним с п/4-DQPSK, однако позволяет смещение фазы в любое из восьми возможных положений.

Стандарт 2.0 определяет десять новых типов пакетов – по 5 для режимов передачи 2Х и 3Х. Два из этих пяти пакетов являются 3- и 5- слотовыми eSCO (extended synchronous connection oriented) пакетами, которые используют зарезервированный диапазон и применяются для голосовой связи. Другие три пакета представляют собой 1-, 3- и 5- слотовые ACL (asynchronous connectionless) пакеты, применяемые для передачи данных.

При этом ни для одного типа пакетов не применяется FEC (forward error correction). Вместо этого существующий алгоритм CQDDR (channel quality driven data rate) дополнен вохможностью по автоматическому возврату к рабботе со стандартными пакетами с FEC.

Отдельно стоит обратить внимание на то, как в заголовке пакета идентифицируются новые пакеты данных EDR. Это стало особенно важным, потому что именно по этой информации приемник переключает схемы модуляции при переходе от заголовка к непосредственно данным. Заголовок пакета содержит 4 бита для идентификации, пригодных для различия 15 типов пакетов, определенных в стандарте версии 1.1. Таким образом, добавление новых 10 типов пакетов EDR и 3 дополнительных пакетов eSCO для стандартной скорости передачи приводит к недостаточности размера поля структуры заголовка. Изменение формата приведет к потере обратной совместимости, что недопустимо.

Решением явилось определение различных режимов действия для соединения и создание нового сообщения, которым обмениваются EDR-совместимые устройства для смены режимов. Одним из таких режимов является передача со скоростью 1 Мбит/с, не отличающийся от стандартной скорости. При соединении двух устройств EDR, они могут посредством обмена сообщениями договориться о переходе в режим 2- или 3- Мбитного соединения, где один и тот же код пакетного заголовка означает различные параметры.

Кроме этого,существует вероятность, что для работы в режиме EDR 3Х потребуется наличие буферизация данных, то есть дополнительная RAM.

2.5. Технология GPRS

GPRS - это стандарт ETSI (European Telecommunications Standards Institute) для пакетной коммутации в системах GSM. В настоящее время по всему миру наиболее широко распространены сети на основе GSM и их называют сетями второго поколения (2G). Технология GSM использует вариацию TDMA (time division multiple access) и является наиболее широко используемой из трех основных цифровых беспроводных технологий (TDMA, GSM и CDMA).

GSM оцифровывает и сжимает данные, затем пересылает их по каналу с двумя другими потоками пользовательских данных, каждый в своем собственном временном интервале (в тайм-слоте). Функционирует на частоте либо 900 МГц, либо 1800 МГц. GSM имеет более 120 миллионов пользователей по всему миру и доступен в 120 странах, согласно данным GSM MoU Association. С тех пор, как большинство операторов сетей GSM заключили роуминговые соглашения с иностранными операторами, пользователи продолжают пользоваться своими мобильными телефонами во время путешествий в другие страны.

GPRS является т.н. накладывающейся технологией, распространяемой на сетях GSM, CDMA и TDMA. Эта технология применяет новый метод эффективной передачи пакетных данных по радиосетям. Технология пакетной коммутации основана на методах IP и X.25, оба из которых очень популярны и широко используются во многих сетях. Пакетная коммутация GPRS работает в целом так же, как и пакетная коммутация IP, то есть данные расщепляются на пакеты и пересылаются по назначению разными путями по сети, затем снова собираются на принимающей стороне. Пакетная коммутация GPRS допускает любой существующий трафик IP или X.25 для пересылки данных через радиосеть GPRS.

GPRS использует радиополосу шириной в 200 кГц, и она делится на восемь каналов. Общая емкость каналов составляет 271 кбит/с, но каждый из этих каналов способен передавать потоки данных в 14.4 кбит/с. Теоретически возможна скорость в 115 кбит/с, но в реальных условиях она используется крайне редко или вообще не используется. Средняя скорость в 48 кбит/с является наиболее вероятной оценкой, поскольку точки доступа поделены между множественными пользователями, причем диапазон или расположение приемника будут также зависеть от имеющейся в наличии ширины полосы. Этот результат гораздо лучше, чем могут предложить существующие устройства мобильных коммуникаций, дающие всего 9.6 кбит/с. Другим важным аспектом Интернет-связи через GPRS - и это первое такого рода внедрение для широкополосной сети - является то, что соединение с Интернет непрерывно (всегда «он-лайн»), и в то же время ему не приходится подтягивать ресурсы из точек доступа в то время, когда оно не используется, потому что данные передаются только тогда, когда в этом есть необходимость. Приемник запрашивает информацию, и устройство подтягивает в этот момент радио-ресурсы, а затем снова находится в нерабочем состоянии, пока не начинает принимать запрошенную информацию. Радио-полосы распределяются динамическим образом, в зависимости от типа контента - одновременно несколько или даже больше, в зависимости от того, передается ли текстовое сообщение или «живое» видео. Когда пользователь включает устройство, поддерживающее GPRS, обычно оно автоматически ищет канал GPRS в данной местности. Если соответствующий канал найден, устройство будет пытаться соединиться с сетью.

Сеть GPRS - наложенная сеть, располагающаяся поверх инфраструктур GSM. Ключевые компоненты сети GPRS включают:

• PCU - Блок управления пакетами, дающий возможность станциям GSM пересылать и получать пакеты при GPRS коммуникациях.

• SGSN - Часть инфраструктуры GSM, ответственная за отсылку и получение пакетов от абонентов в своем районе обслуживания. Этот блок также производит авторизацию, контактируя с сервером и проверяя информацию о пользователе. Кроме того, он отслеживает маршрут перемещений абонента, чтобы иметь возможность надлежащим образом распределять ресурсы, а также собирает поступающую биллинговую информацию, пересылая ее в главный офис.

• GGSN - Компонент сети GSM, ответственный за взаимодействие с Интернет и другими общественными сетями, передающими данные и голос. Компонент хранит маршрутизирующую базу данных, базу данных с адресами и фильтрующую базу данных.

• GTP - Туннелирующий протокол GPRS, основанный на протоколах TCP/IP, инкапсулирующий пакеты IP и X.25, приходящие из узлов SGSN в GGSN.

Когда пользователь GPRS делает звонок, устройство GPRS контактирует со станцией GSM, которая в свою очередь обращается к станции SGSN, которая взаимодействует с другими станциями SGSN или станциями GGSN, если ей нужно получить доступ к сети другого рода (IP или X.25). Для пользователя GPRS соединение получается «бесшовным», нет процедуры «установления звонка». Технология GPRS, накладываемая поверх сети GSM, изначально была предназначена для того, чтобы динамически и индивидуально распределять радио-ресурсы GSM «попакетно», по мере необходимости. Если к соте GSM одновременно подключается сразу много пользователей GPRS, и сота GSM не способна поддерживать такой объем голосового трафика, станция GPRS воспользуется радиоресурсами соседних сот GSM. Таким образом, в реальности пользователи GPRS обслуживаются многими сотами GSM одновременно, когда в этом возникает необходимость. Итак, SGSN получает запрос на соединение, запрашивает информацию о профиле пользователя из узла HLR и производит аутентификацию пользователя. В этой точке может осуществляться шифрование. SGSN использует информацию о профиле (включая имя точки доступа, которое идентифицирует сеть и оператора) для определения, к которому узлу GGSN производить маршрутизацию. Выбранные ворота могут предоставлять сервис удаленной аутентификации пользователя (Remote Authentication Dial-In User Service, RADIUS) и назначать динамический адрес Интернет-протокола (IP) пользователю перед настройкой соединений во внешние сети. Этот процесс называется "контекстная активация пакетного профиля данных" и установки могут варьироваться от оператора к оператору. Он может включать дополнительные функции, такие как менеджмент QoS (Quality of Service - качество сервиса) и менеджмент виртуальных частных сетей (virtual private network, VPN). Когда мобильное устройство выключено или находится вне зоны покрытия GPRS, его контекст дезактивируется и устройство отсоединяется от сети.

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

Использование настоящей технологии позволяет получить ряд преимуществ по сравнению с работой в сетях GSM без нее:

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

- увеличение скорости передачи данных

- GPRS в настоящее время поддерживает средние скорости передачи данных порядка 115 кбит/с, но такие скорости достигаются только при задействовании всех восьми тайм-слотов (промежутков времени) для GPRS. Вместо этого носители и конечные устройства будут конфигурироваться типовым образом, чтобы работать с определенным количеством тайм-слотов для данных, передаваемых в обоих направлениях. Например, устройство GPRS может быть настроено для работы максимум с четырьмя слотами в прямом направлении и двумя слотами в обратном направлении. В хороших радиоусловиях это дает скорости приблизительно в 50 кбит/с в прямом направлении и 20 кбит/с в обратном направлении. Это более чем в три раза быстрее, чем в нынешних сетях GSM (14.4 кбит/с) и того же порядка, что и при хорошем модемном аналоговом соединении в кабельной линии. Совокупная ширина полосы узла сотовой связи делится между голосовым трафиком и трафиком данных. Операторы GPRS по-разному используют эту ширину полосы. Обычно они конфигурируют сети, давая приоритет голосовому трафику; некоторые из них назначают тайм-слоты для трафика данных, чтобы гарантировать минимальный уровень этого сервиса в высокозагруженные голосовым трафиком промежутки времени. Неиспользованная емкость, зарезервированная под голосовой трафик, может быть динамически переопределена под передачу данных. Имея более высокие скорости передачи данных, GPRS дает возможность реализации приложений, требующих более высокой ширины полосы и в настоящее время не осуществимых на сетях GSM.

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

GPRS улучшила целостность передачи данных путем применения ряда механизмов. Во-первых, пользовательские данные кодируются с некоторой избыточностью, что улучшает их устойчивость к неблагоприятным радиоусловиям. Уровень избыточности при кодировании можно варьировать, в зависимости от тех же радиоусловий. GPRS определяет четыре кодирующие схемы - с CS1 по CS4. Вначале поддерживаются только CS1 и CS2, которые обеспечивают примерно 9 и 13 кбит/с на каждый тайм-слот. Если в полученном фрейме обнаружена ошибка в BSS, этот фрейм до передачи его на центральную сеть GPRS периодически повторяется, пока не будет получен в приемлемом качестве.

Подобно сети Интернет, GPRS основан на пакетной коммутации данных. Это означает, что все собственные IP приложения могут быть реализованы в рамках GPRS - такие как e-mail, Web-доступ, мгновенная передача сообщений и передача файлов. Кроме того, его более высокие скорости передачи данных дают возможность GPRS осуществлять работу приложений, требующих большей ширины полосы (таких как мультимедийный веб-контент), которые не идут в условиях более медленных GSM dial-up соединений. GPRS более-менее хорошо подходит для приложений, основанных на Wireless Application Protocol (WAP). WAP достиг широкого распространения в новом поколении мобильных телефонов, поддерживающих микробраузеры.

GPRS строится на проверенной на практике модели аутентификации и авторизации, используемой GSM. При инициации сессии пользователя аутентифицируют, используя секретную информацию, содержащуюся на смарт-карте, называемой «модуль идентификации абонента» (Subscriber Identity Module, SIM). Аутентификационные данные посылаются на узел сети HLR и там подтверждаются. GPRS дает возможность дополнительной аутентификации путем использования таких протоколов как RADIUS - перед тем, как абонентам будет разрешен доступ в Интернет или корпоративную сеть данных. GPRS поддерживает шифрование пользовательских данных при передаче через беспроводный интерфейс с мобильного терминала на SGSN. Кроме того, может иметь место высокоуровневое сквозное шифрование VPN (Virtual Private Network), когда пользователь подсоединяется к частной корпоративной сети.

Под идентификацией в данном случае понимается подтверждение права человека на использование данного сотового телефона. В этом плане технология GPRS ничем не отличается от стандарта GSM. То есть в ней используются те же самые средства идентификации: PIN-коды и PUK-код. С их помощью человек подтверждает собственную личность, точнее, право на использование телефона.

Аутентификация же необходима для подтверждения телефоном своего права работать в данной сети GPRS. Для этого в SIM-карте мобильного телефона и на базовой станции реализован специальный алгоритм. Суть его заключается в следующем. В начале процедуры базовая станция отправляет на телефон случайную последовательность цифр. SIM-карта преобразовывает его в соответствии с алгоритмом, используя при этом собственный секретный ключ, а получившееся значение (SRES, Signed RESult - подписанный результат) отправляет обратно. Точно такие же преобразования производятся и на базовой станции. Если оба значения SRES совпадают, то делается вывод о допуске данного телефона в сеть. Таким образом, идентификация пользователей и аутентификация мобильников должны предотвратить несанкционированный доступ к базовой станции, а также использование злоумышленниками чужих счетов.

Можно сказать, что в сети GPRS используется два типа каналов связи. Первый из них - это радиоэфир, через который общаются между собой базовые и мобильные станции. Данный канал является наиболее уязвимым местом GPRS-сети. И действительно, перехват радиосигналов не представляет собой практически никакого труда. Для этого можно использовать как специализированные устройства (в том числе и самодельные, сделанные любителями), так и старые радиоприемники советского образца. Именно поэтому абсолютно вся информация, передающаяся по радиоканалу, предварительно зашифровывается с помощью специальных алгоритмов. В сетях GPRS для этого используются стандарты GEA1, GEA2, GEA3 - "близкие родственники" криптоалгоритмов GSM.

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

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

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

Под внешними угрозами понимаются вирусы или удаленные атаки. Если рассмотреть архитектуру сети GPRS, то станет ясно, что все это угрожает только одному узлу - узлу маршрутизации. Для того, чтобы выполнять свои функции, он должен быть полноценным участником обеих сетей. Так что он подвержен всем видам атак, которые на данный момент существуют в Интернете. Эта проблема отлично решается с помощью обычных средств: антивирусной программы с постоянно обновляемыми базами данных и корректно настроенного файрвола. Единственным отличием защиты данного компьютера является использование принципа трансляции адресов (network address translation). Это необходимо для предотвращения удаленного доступа злоумышленников к внутреннему сетевому оборудованию. Нерешенной остается только одна проблема. Речь идет о возможности проведения на узел маршрутизации профессиональной DDoS-атаки. От этого не застрахован ни один сервер в Интернет.

Узел маршрутизации выполняет еще одну функцию. Он отвечает за связи своей сети GPRS с другими такими же сетями. Для того чтобы защитить эти каналы, используются так называемые пограничные шлюзы (BG - border gateway). Суть действия этого программного обеспечения похожа на работу файрвола. Администратор устанавливает правила обмена трафиком, вводит доверенные сети, подключает системы роуминга и т. п. После этого вся система будет защищена от атак из других сетей GPRS.

В технологии GPRS существует ряд ограничений:

- GPRS оказывает существенное влияние на существующую емкость соты сети. Объем имеющихся радиоресурсов, которые могут быть использованы для различных целей, ограничен, причем использование ресурсов для одной цели препятствует одновременному их использованию для других. Например, и голосовые вызовы, и GPRS-сессии используют одни и те же сетевые ресурсы. Ощутимость влияния зависит от количества тайм-слотов, зарезервированных для эксклюзивного использования GPRS, если это имеет место быть. Однако в действительности GPRS динамически управляет назначением каналов и позволяет уменьшать нагрузку канала сигнала в пиковое время путем пересылки коротких сообщений по GPRS каналам. Результат: Потребность в SMS как в дополнительном носителе, использующем другой тип радиоресурсов.

- достижение теоретически максимальной скорости передачи данных через GPRS - 172.2 кбит/с потребовало бы, чтобы отдельный пользователь использовал все восемь тайм-слотов без какой-либо защиты от ошибок. Ясно, что на практике достаточно маловероятно, чтобы оператор сети позволил использовать все тайм-слоты одному пользователю GPRS. Кроме того, «первое поколение» GPRS-терминалов жестко лимитировано на поддержку всего одного, двух или трех тайм-слотов. Поэтому ширина полосы, доступная пользователю GPRS, так же жестко лимитирована. По этой причине теоретические максимальные скорости GPRS не могут быть достигнуты в реальных сетях и на реальных терминалах. Реальность такова, что мобильные сети, вероятно, всегда будут иметь более низкие скорости передачи данных, по сравнению с фиксированными сетями. Результат - относительно высокие скорости передачи данных через мобильные устройства могут не быть доступными индивидуальным пользователям мобильных сервисов, пока не появились возможности существенного повышения скоростей на сетях GSM Evolution (EDGE) или Universal Mobile Telephone System (3GSM).

- GPRS основан на технологии модуляции, известной как GMSK (Gaussian minimum-shift keying). Сети EDGE основаны на новой модуляционной схеме, допускающей гораздо более высокие скорости передачи данных через воздушный интерфейс - это называют модуляцией 8 PSK (eight-phase-shift keying). Поскольку 8 PSK также будет использоваться в 3GSM, сетевым операторам потребуется учесть этот момент на некоторой стадии перехода к сетям мобильной связи третьего поколения. Вывод -необходимость EDGE.

- пакеты GPRS посылаются по всем направлениям, чтобы в итоге достичь одного и того же пункта назначения. Это создает опасность того, что один или несколько таких пакетов потеряются или будут повреждены во время передачи данных по радиосвязи. Стандарты GPRS учитывают это неотъемлемое свойство беспроводных пакетных технологий, закладывая в свои стратегии задачи сохранения целостности данных и ретрансмиссии. Однако в результате этой подстраховки могут происходить задержки передачи. Вследствие этого приложения, требующие высокого качества передачи видеоизображений, могут выполняться на должном уровне при использовании HSCSD (High Speed Circuit Switched Data, высокоскоростная коммутация каналов данных). HSCSD - это просто коммутация каналов данных, при которой отдельный пользователь может использовать до четырех разных каналов одновременно. Из-за принципа сквозной связи между отправителем и получателем, задержки передачи менее вероятны. Вывод - необходимость HSCSD.

2.6. Технология EDGE, технологии 3G

Следующим шагом развития мобильных систем передачи данных является технология EDGE (Enhanced Data Rates for GSM Evolution - «передача данных на повышенной скорости»), которая позволит осуществлять перекачку информации на скоростях до 384 кбит/с в восьми GSM-каналах (48 кбит/с на канал). Для внедрения EDGE «поверх» GPRS операторам предстоит заменить аппаратуру базовых станций, а пользователям – приобрести поддерживающие EDGE телефонные аппараты.

Эволюцией технологии GSM является стандарт EDGE (Enhanced Data rates for Global Evolution), позволяющий повысить пропускную способность до 384 кбит/с. Радиоинтерфейс EDGE надстраивается над существующей инфраструктурой GSM и использует те же полосы частот 850/900/1800/1900 Гц, что и GSM. Полоса пропускания, необходимая для мобильных Интернет-услуг, обеспечивается в GSM за счет предварительной организации общей радиослужбы пакетной передачи (GPRS). Однако, для приложений, работающих с данными в реальном времени, требуется более широкая полоса пропускания и более высокое качество обслуживания по сравнению с теми, которые обеспечивают современные системы GPRS. Эта нехватка компенсируется путем замены гауссовской манипуляции с минимальным частотным сдвигом (GMSK), которая использует только часть фазы, на восьмипозиционную фазовую манипуляцию (8PSK), которая использует все 360º.

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

В зависимости от качества связи предусмотрено 9 алгоритмов кодирования от MCS-1 до MCS-9 (последний обладает самой малой избыточностью кодирования, соответственно – самый быстрый).

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

Технологии GPRS и EDGE считают лишь промежуточными этапами миграции к 3G и зачастую их называют переходными технологиями поколения 2.5G.

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

Одно из главнейших требований – сеть 3G должна передавать данные от абонента и обратно со скоростью до 2.048 Мбит/с при низкой мобильности (скорость – менее 3 км/ч) и локальной зоне покрытия и до 144 кбит/с при высокой мобильности (до 120 км/ч) и широкой зоне покрытия.

Сегодня в мире существуют две основные конкурирующие концепции 3G: UMTS (Universal Mobile Telecommunications Systems – универсальная мобильная телекоммуникационная система), поддерживаемая европейскими странами, и CDMA 2000 (Code Division Multiple Access – мультидоступ с кодовым разделением каналов), сторонниками которой традиционно являются азиатские страны и США.

В принципе эти две технологии предполагают два различных подхода к организации сетей 3G: революционный (UMTS) и эволюционный (разновидности CDMA – CDMA2000, CDMA2000 IX, CDMA2000 IX EvDo). Эволюционный путь подразумевает сохранение частот и постепенный переход к новым технологиям, путем наращивания технических мощностей оператора. UMTS – совершенно новый стандарт, в то время как разновидности CDMA, предложенные для 3G, являются развитием уже эксплуатирующейся в мире технологии второго поколения cdmaOne (IS-95).

3. Компоненты программной среды мобильных устройств

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

Решением многих проблем в данной области явилась платформа Java 2 Micro Edition (J2ME) [11]. Спецификой языка java в рамках данной платформы является оптимизация под ограниченные в ресурсах и возможностях устройства. Фактически, можно представить, что 80% функциональности стандартного языка java из поставки для платформы Java 2 Standard Edition (J2SE) доступны на J2ME с использованием только 20% ресурсов, требующихся на полномасштабной конфигурации.

Альтернативой платформе на java является семейство Windows Mobile компании Microsoft. В него входят ряд ОС, предназначенных для установки на устройства с ограниченными возможностями, например, на органайзеры, коммуникаторы и КПК. Под их управлением возможна разработка и установка пользовательских приложений, причем инструментарий для разработки представляется более обширным, нежели на платформе J2ME [11].

Однако, если сравнить средства разработки приложений с использованием беспроводных технологий связи, представленные семейством платформ MS Windows Mobile и платформой Sun Java Mobile Edition, то возможно заключить, что последней они представлены в более выгодном свете в виде комбинации интерфейса (JSR82) и инструментария (например, Impronto SDK). В случае же платформ компании Microsoft разработчику предоставляется огромный простор для выбора средств разработки, в конечном итоге приводящий к драйверу модуля устройства беспроводной связи, интерфейс которого не всегда публикуется. Поэтому целесообразно подробнее рассмотреть способы программирования беспроводных соединений на java, сохраняя надежду на то, что в будущем аналогичные возможности будут представлены под управлением платформы Windows.

3.1. Среда программирования Java

Возможности и потребности разных компьютерных систем достаточно различны. Для сглаживания этих различий существует ряд сред программирования Java, называемых «edition» - редакция. Они предназначены для различных целей, однако, являются членами одного семейства сред одного языка java. На рис 3.1 приводится обзор сред программирования Java.

Различия между средами заключается в используемых виртуальных машинах, а также во включаемых классах. Классы определяют объекты с различными наборами функций. Эти классы объединяются в библиотеки классов и интерфейсы программирования (АРI). Каждая редакция включает определенный набор интерфейсов. Классы или интерфейсы, не включенные в редакцию, могут распространяться механизмом расширения Java в качестве опциональных пакетов. J2SE содержит базовый набор интерфейсов, которые удовлетворят потребности средней домашней или офисной системы. Серверным конфигурациям обычно подходит J2EE (Java 2 Enterprise Edition), дополнительно включающей интерфейсы, необходимые для работы с сетевыми решениями.

Рис.3.1. Среды программирования платформы Java 2

Мобильные и встраиваемые системы (начиная с пейджеров и мобильных телефонов и заканчивая портативными компьютерами) обслуживаются платформой J2ME. Благодаря изменчивости требований и конфигураций устройств платформа была сконструирована более гибкой, чем остальные редакции, и в то же время поддерживающей совместимость языка и масштабируемость. Это стало возможно благодаря использованию концепции конфигураций и профайлов, что позволяет платформе размещаться на устройствах различных типов без определения  новой среды для каждой установки. Конфигурация устанавливает минимальный базис для семейства или класса устройств, в то время как профайл нацелен на специфичные требования категории устройств или сегмента рынка. Конфигурации и профайлы устанавливаются JCP (Java Community Process) – открытой организацией, разрабатывающей псевдо-стандарты, состоящей из разработчиков и производителей.

Оптимальной J2ME для мобильных телефонов делает модель «sandbox», позволяющая производителям устройств предоставлять потребителям возможность устанавливать и запускать приложения без опасения, что их программа станет причиной выхода устройства из строя, как в случае С и С++. Приложение в «песочнице» может работать только с теми ресурсами, которые в ней находятся или имеют определенный интерфейс. Это означает, что приложения гораздо более контролируемы и, в случае ошибки, будут сняты без ущерба системе в целом. В отличие от программного обеспечения рядовых телефонов, которое устанавливаются в специализированных сервис-центрах, платформа J2ME предоставляет пользователям возможности по установке программ на устройства. Поэтому обновления и заплатки могут инсталлироваться «на ходу».

Рис.3.2. Иерархия J2ME

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

3.2. Конфигурации

Конфигурация определяет среду программирования ядра J2ME для широкой категории устройств с похожими требованиями к сетевым возможностям, объему памяти и вычислительной мощности. Она определяет способности виртуальной машины java и основные классы, которые должны быть реализованы, а также поддерживаемые возможности по безопасности и установке. В настоящий момент существует два вида конфигураций – Connected Device Configuration (CDC) и более ограниченная Connected Limited Device Configuration (CLDC) [4]. Некоторые параметры и представители этих двух конфигураций приводятся в табл. 3.1 (приложение 1).

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

Классы, определяемые конфигурацией J2ME являются набором классов J2SE или собственными классами J2ME. Последние обозначаются пространством имен javax.microedition.* в соответствии со спецификацией расширений стандарта java. Хотя не все классы наследованы из J2SE, менее объемлющая конфигурация должна включаться более объемлющей, чтобы не нарушить совместимость. Таким образом, классы CLDC включаются конфигурацией CDC.

Рис.3.3. Отношения между конфигурациями J2ME и J2SE

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

Конфигурация портативных устройств с ограниченными ресурсами

CLDC является наиболее базовой конфигурацией, доступной на J2ME. Она определяет стандартную, портируемую среду java для малых, ограниченных в ресурсах мобильных устройств. Будучи применимой к полному спектру устройств потребителей, она нацелена на использование в питаемых батареями приборах с объемом памяти от 160 до 512 КВ. Поддерживаются 16-ти и 32-разрядные процессоры, без ограничений на минимальную производительность. Типичными устройствами такой конфигурации являются мобильные телефоны, КПК, дуплексные пейджеры, которые регулярно связываются с сетью, часто беспроводной и с узкой шириной канала.

Виртуальная машина CLDC очень компактная, устроенная так, чтобы быть как можно более совместимой со стандартной JVM. С объемами памяти, измеряемыми сотнями килобайт, потребовались некоторые изменения. Кроме этого, необходимо было внести поддержку несколько другим условиям безопасности. Основные ограничения CLDC:

1.                   отсутствует поддержка вычислений с плавающей точкой;

2.                   отсутствует поддержка JNI (Java Native Interface);

3.                   отсутствуют определяемые пользователем загрузчики классов java-уровня;

4.                   отсутствует поддержка группам нитей или нитям демонов;

5.                   отсутствует поддержка финализации экземпляров классов;

6.                   отсутствуют слабые ссылки;

7.                   упрощенный аппаратный процесс верификации классов;

8.                   потенциально некомпактный сборщик мусора (до CLDC 1.0.2);

9.                   ограничения на обработку ошибок;

10.               ограниченный интерфейс отладки.

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

Реализация виртуальной машины CLDC называется Kilo VM (KVM) и поставляется компанией Sun, однако производители устройств могут разрабатывать собственные реализации.

Обобщенный механизм соединения

Кроме общих модификаций JVM CLDC также упрощает и обобщает другие части стандартных библиотек и функциональности Java. Например, используется Generic Connection Framework – фреймворк для работы со всеми типа соединений. Необходимость в новом фреймворке вместо использования стандартных процедур вызвана желанием поддержать множество сетевых технологий и способов ввода/вывода на базе общей структуры, что делает работу с соединениями более легкой и простой. GCF состоит из одного класса и семи предопределенных интерфейсов соединений с внутренней иерархией, показанной на рисунке.

Рис.3.4. Иерархия интерфейсов GCF CLDC

С их помощью идет обращение к шести базовым типам интерфейсов:

1.                   базовый серийный ввод;

2.                   базовый серийный вывод;

3.                   датаграммно-ориентированные коммуникации;

4.                   схемно-ориентированные коммуникации;

5.                   базовые соединения с HTTP-сервером;

6.                   механизм информирования серверного приложения о клиентских соединениях.

Соединения с перечисленными интерфейсами могут осуществляться с помощью класса Connector и его метода open(). На вход ему передается совместимый с RFC 2396 Uniform Resource Indicator (URI), представляющий собой строку параметров, которые описывают протокол соединения и конечную цель. Принятие решения использовать те или иные протоколы предоставлено производителю устройства и зависит от возможностей конкретного устройства. Некоторые протоколы могут быть востребованы используемым видом профайла. Например, профайлу MIDP (Mobile Information Device Profile) необходима поддержка протокола http. Запрос на открытие соединения с применением протокола, который не поддерживается устройством, вызовет проброс исключения.

Пре-верификация

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

Перед загрузкой класса на устройство он обрабатывается средством пре-верификации. Это средство анализирует каждый метод в файле класса и вставляет специальные атрибуты, активирующие встроенный в устройство механизм верификации для подтверждения безопасности типов через линейное сканировании байткода. Атрибуты соответствуют механизму расширений стандартной виртуальной машины JVM и поэтому автоматически игнорируются обычными верификаторами классов. Благодаря этому предложенное решение полностью совместимо с технологией J2SE. Прирост размера файлов классов составляет при этом около 5%.

Благодаря тому, что верификация байткодов в рантайме гарантирует безопасность типов, даже битые классы не смогут вызвать конфликт в системе типов виртуальной машины и, следовательно, повредить память. Метод безопасен, так как встроенный верификатор не должен полностью доверять добавленным атрибутам. Отсутствие или неудачная верификация по атрибутам приводят к тому, что класс отвергается верификатором. Поэтому процесс пре-верификации соответствует строгому стандарту безопасности Java.

Конфигурация встраиваемых и портативных устройств

CDC нацелена на высокотехнологичные устройства с емкостью памяти минимум 2МВ и соответствующей мощностью процессора. Типичными представителями этой категории являются цифровые телевизоры, навигационные системы автомобилей [21] и коммуникаторы, которым необходим более искусный набор функциональности, чем может предоставить CLDC. CDC обладает полностью совместимой виртуальной машиной CVM и минимальным набором классов, необходимых конфигурации системы и установке приложений, таких как минимальные возможности по безопасности и ограниченный доступ к сети и файлам. Конфигурация также поддерживает определенный в CLDC GCF. На базе GCF поддерживаются файловый и датаграммный протоколы.

CDC рассчитан на использование с профайла Foundation, предоставляющего остальную часть базовых классов и библиотек J2SE за исключением AWT (Abstract Windowing Toolkit), используемого для создания графических интерфейсов (GUI – Graphical User Interface). Для приложений, использующих GUI, необходимо подключать дополнительные профайлы. Хотя CDC с профайлом Foundation формируют полностью совместимую с J2SE версии 1.3 среду, есть одно значительное изменение. Для снижения размеров библиотек были исключены наиболее противоречивые методы и классы. Под противоречивостью понимается то, что функциональность класса или метода была замещена более корректной реализацией, которая должна использоваться разработчиками. В результате исключения противоречивых API приложения, созданные на Java версии 1.3 и более старшими, не поддерживаются комбинацией CDC и профайла Foundation. В подавляющем большинстве случаев это не является реальной проблемой, так как приложениям свойственно подвергаться переработке для использования во встраиваемых устройствах. В качестве стандарта при компиляции программы с использованием компилятора J2SE при вызове противоречивого метода выдается предупреждение.

Виртуальная машина CDC также претерпела оптимизацию для использования во встраиваемых устройствах. В результате размер снизился на 40% в сравнении со стандартной JVM и на 17% в сравнении с PersonalJava. Другие аспекты оптимизации включают поддержку выполнения заранее загруженных байткодов вне ROM, что обеспечит лучшее время запуска и меньшую фрагментацию. Код должен быть заранее прилинкован с использованием JavaCodeCompact.

3.3. Профайлы

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

Как и конфигурации, профайлы определяются JCP. Каждый из них разрабатывается группами экспертов, формируемыми при внесении Java Specification Request (JSR). Хотя этот процесс необходим для официальной сертификации, существует несколько профайлов, определенных вне JCP частными корпорациями. Некоторые профайлы доступны сегодня, некоторые находятся в разработке. Их список с перечислением основных характеристик приводится в табл. 3.2 (приложение 1).

Профайлы, основанные на CLDC

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

Профайл MIDP

MIDP сегодня считается наиболее важным профайлом для мобильных устройств. MID считается устройством, которое есть в кармане у каждого. Им может быть и мобильный телефон, и даже простой дуплексный пейджер. Обычно у подобных устройств относительно маленький экран, и они работают на батарейках.

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

 Профайлы, основанные на CDC

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

Профайл RMI

Профайл RMI предоставляет те же возможности по RMI, что и стандартный пакет Java RMI, для устройств с ограниченными ресурсами. Заметное различие между этим и другими профайлами – необходимость в подключении к TCP/IP.

3.5. Методы построения беспроводных соединений

Беспроводное соединение Bluetooth организовано по принципу «клиент-сервер». Сценарий взаимодействия предполагает, что устройство-сервер, предоставляя свои ресурсы для использования клиентом, регистрирует т.н. сервис [6]. С его помощью клиент определяет, с каким именно сервером ему необходимо соединиться. То есть в зоне охвата радиосвязи клиента может находиться несколько устройств – серверов Bluetooth, предоставляющих как совершенно различные, так и совпадающие сервисы. Получив описание подходящих сервисов, клиент выбирает, кому адресовать запрос о соединении.

Рис.3.5. Стек протоколов Bluetooth

Программно управление соединением Bluetooth осуществляется с помощью стека протоколов – SDP, RFCOMM, L2CAP, OBEX и др.

Протокол работы с сервисами (SDP – Service Discovery Protocol) определяет регламент и методы создания в соответствующей базе данных (SDDB – Service Discovery Database) записей о сервисах, которые поддерживаются серверами, и обнаружения этих записей клиентами.

Протоколы L2CAP (Logical Link Control and Adaptation Protocol) и OBEX (OBject EXchange Protocol) предоставляют механизм обмена данными между устройствами на основе протоколов более высоких уровней стека RFCOMM и SDP. В частности, RFCOMM (Radio Frequency (RF) emulation of serial COM port) эмулирует последовательный порт RS232 на базе радиоканала.

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

Для разработчика интерес представляет возможность разработки собственного приложения, использующего Bluetooth-соединение. Одну из возможностей реализации подобной идеи предоставляет платформа J2ME (Java 2 Micro Edition), предназначенная для поддержки Java-приложений на мобильных устройствах. J2ME содержит собственную виртуальную машину (КVM – Kilo Virtual Machine). Чтобы определить возможности мобильного устройства и то, какие API на нем доступны, были введены понятия стандартных конфигураций и профайлов. Дополнительная функциональность (возможность программирования отдельных аппаратно поддерживаемых действий, например, получение данных со встроенной камеры, работа с соединениями Bluetooth) определяется тем, какие Java API поддерживаются конкретным устройством [7].

Например, JSR135 определяет интерфейс для получения и работы с байтовыми массивами цифровых снимков камер мобильных телефонов, JSR82 определяет интерфейсы для установления соединения Bluetooth и обмена данными по протоколу OBEX.

Технология разработки приложения для мобильного устройства незначительно отличается от создания апплета для ПК. Мидлет (MIDlet – приложение, удовлетворяющее MIDP) представляет собой архив JAR, куда включены байткоды разработанных программистом классов, а также некоторая сервисная информация. Существует ряд способов размещения мидлета на мобильном устройстве, но самый простой и удобный - с помощью прямого соединения, например, кабельного.

Специализированные среды разработки для J2ME позволяют проверить работоспособность созданных классов на эмуляторе мобильного устройства. Например, пакет Sun Java Studio Mobility, помимо удобного интерфейса разработчика, предоставляет возможность отладки на нескольких конфигурациях виртуального мобильного телефона средствами встроенного эмулятора Wireless ToolKit.

Протокол работы с сервисами SDP

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

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

1.    Организует единую систему идентификации сервисов, их классов и атрибутов.

2.    Позволяет искать сервисы по их атрибутам.

3.    Позволяет искать сервисы по их классу.

4.    Дает возможность получать данные о сервисах только по из идентификатору.

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

6.    Дает возможность определить, когда сервис становится недоступным.

7.    Позволяет клиенту найти сервис на другом устройстве напрямую, без привлечения устройств-посредников.

8.    Может использоваться на устройствах с ограниченной сложностью.

9.    Реализует механизм последовательного получения данных о сервисе.

Одно физическое устройство-сервер может управляться только одним сервером SDP, на клиентском устройстве сервер протокола не требуется. Однако ничто не мешает иметь на устройстве одновременно как сервер, так и клиент.

Прежде чем клиенты смогут воспользоваться услугами SDP-сервера, на нем необходимо зарегистрировать соответствующие сервисы – при этом в базу заносятся определенные записи. Запись содержит различные атрибуты, в том числе и уникальный для данного сервера идентификатор сервиса. Это 32-битная величина, значения которой однозначно характеризуют сервис. Значения в интервале 0х00000000-0х0000FFFF зарезервированы.

Атрибуты сервисов могут быть представлены в виде целочисленных значений, строк или UUID (Universally Unique IDentifier) размером 128 бит.  Атрибуты могут использоваться при поиске сервисов на основе шаблона.

В шаблон можно включить до 12 UUID.

Отдельным атрибутом задается доступность сервиса, представляемая 8-битной беззнаковой величиной. Она рассчитывается на основании зависимости (1 - число_клиентов / максимум_клиентов) * 0хFF.

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

Протокол обмена данными объектов OBEX

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

Подключение к серверу инициируется клиентской стороной. Клиент направляет серверу сообщения типа SETPATH (изменение текущей или создание новой директории на сервере), GET (получение объекта с сервера), PUT (передача объекта на сервер), ABORT (прерывание текущей операции Put или Get), DISCONNECT (завершение соединения). На любой запрос клиента сервер обязательно отвечает; запрос-ответ составляют операцию OBEX.

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

Классы, интерфейсы и методы пакета javax.bluetooth

Пакет javax.bluetooth содержит ряд классов:

1.    DiscoveryAgent

2.    LocalDevice

3.    RemoteDevice

4.    UUID

5.    DeviceClass

6.    DataElement

и интерфейсов:

1.    DiscoveryListener

2.    ServiceRecord

3.    L2CAPConnection

4.    L2CAPConnectionNotifier

Рассмотрим их подробнее.

Класс javax.bluetooth.DiscoveryAgent

Класс DiscoveryAgent предназначен для поиска и опроса доступных Bluetooth-устройств. Этим целям служат следующие методы:

boolean startInquiry(int accessCode, DiscoveryListener listener)

начинает поиск Bluetooth-передатчиков. В зависимости от значения аргумента accessCode (DiscoveryAgent.GIAC или DiscoveryAgent.LIAC) производится поиск устройств, находящихся в режимах Limited Discoverable Mode (LIAC - Limited Inquire Access Code) или General Discoverable Mode (GIAC – General Inquire Access Code).  Эти режимы определяют доступность Bluetooth-устройства для обнаружения. General Discoverable Mode – это режим, в котором устройство постоянно доступно для обнаружения. Limited Discoverable Mode – режим, в котором устройство доступно для обнаружения только в течение установленного периода времени.

RemoteDevice[] retrieveDevices(int option)

возвращает список заранее предопределенных устройств (аргумент option – DiscoveryAgent.PREKNOWN) или список устройств, предварительно найденных в процессе поиска (аргумент option – DiscoveryAgent.CACHED).

int searchServices(int[] attrSet, UUID[] uuidSet, RemoteDevice btDev, DiscoveryListener discListener)

вызывается с целью поиска сервисов на конкретном устройстве-сервере.

Интерфейс javax.bluetooth.DiscoveryListener

Интерфейс DiscoveryListener, реализуемый клиентским классом, содержит ряд методов:

void deviceDiscovered(RemoteDevice btDevice, DeviceClass cod)

вызываемый в случае обнаружения Bluetooth-устройства процедурой startInquiry класса DiscoveryAgent.

void servicesDiscovered(int transID, ServiceRecord[] servRecord)

вызываемый в случае обнаружения сервисов в процессе работы метода searchServices класса DiscoveryAgent.

Таким образом, для поиска серверов и сервисов клиентский модуль должен использовать методы класса DiscoveryAgent. При этом сам клиентский класс должен реализовывать интерфейс DiscoveryListener, чтобы обрабатывать события обнаружения сервера, сервиса, окончания поиска и т.д.

Класс javax.bluetooth.LocalDevice

Методы класса LocalDevice позволяют получить информацию о параметрах локального Bluetooth-устройства. Объект получается статическим методом:

static LocalDevice getLocalDevice()

Физический адрес устройства в виде строки можно получить методом:

String getBluetoothAddress()

Кроме этого, методом:

ServiceRecord getRecord(javax.microedition.io.Connection notifier)

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

void updateRecord(ServiceRecord srvRecord)

При этом аргумент notifier – это объект типа javax.microedition.io.Connection – соединение, ожидающее клиента.

Методами:

int getDiscoverable()

boolean setDiscoverable(int mode)

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

Интерфейс javax.bluetooth.ServiceRecord

Этот интерфейс определяет запись сервиса Bluetooth, которая состоит из пар идентификатор-значение атрибута. Идентификатор представляет собой 16-битное беззнаковое целое, а значение имеет тип DataElement. Помимо функций для работы со значениями атрибутов интерфейс включает метод получения URL сервера:

java.lang.String getConnectionURL(int reqSec, boolean mustBeMaster)

Класс javax.bluetooth.DataElement

Класс содержит различные типы данных, которые может принимать значение атрибута сервиса, например:

7.    знаковые и беззнаковые целые длиной 1,2,4,8 или 16 байт;

8.    строка;

9.    boolean;

10.UUID;

11.последовательность вышеперечисленных типов.

Методы класса предусматривают возможности получения и установки значений.

Класс javax.bluetooth.UUID

Класс инкапсулирует беззнаковые целые длиной 16, 32 или 128 бит. Он используется для представления значений атрибутов, так как поиск средствами протокола SDP осуществляется только среди объектов типа UUID. Существует методика перевода 16- и 32-битных UUID в 128-битные, которыми оперирует технология поиска.

Классы, интерфейсы и методы пакета javax.obex

Пакет javax.obex содержит классы:

1.    ServerRequestHandler

2.    ResponseCodes

3.    PasswordAuthentication

и интерфейсы:

1.    ClientSession

2.    HeaderSet

3.    Operation

4.    SessionNotifier

5.    Authenticator

Рассмотрим их подробнее.

Класс javax.obex.ServerRequestHandler

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

int onConnect(HeaderSet request, HeaderSet reply)

вызывается при инициировании клиентом процесса соединения с сервером и получении запроса CONNECT.

int onGet(Operation op)

вызывается при получении от клиента запроса GET.

int onPut(Operation op)

вызывается при получении от клиента запроса PUT.

Интерфейс javax.obex.HeaderSet

Интерфейс HeaderSet определяет методы задания и получения значений заголовков пакетов OBEX. С помощью метода

void setHeader(int headerID, java.lang.Object headerValue)

можно устанавливать значения полей (если такого поля не существовало ранее, оно будет создано), а метод

java.lang.Object getHeader(int headerID) 

предназначен для получения значений этих полей.

Интерфейс javax.obex.Operation

Интерфейс Operation позволяет работать с операциями PUT или GET. Он наследуется от интерфейса javax.microedition.io.ContentConnection и обладает методами для работы с потоками данных. С их помощью можно открывать потоки на прием и на передачу, считывать из них или помещать в эти потоки данные.

Кроме этого, методы:

HeaderSet getReceivedHeaders()

void sendHeaders(HeaderSet headers)

дают возможность, соответственно, получать и отправлять заголовки.

В общем виде процесс обмена данными между клиентом и сервером с помощью операций PUT и GET можно представить следующим образом. Клиент инициирует отправку данных методом put или прием информации от сервера методом get интерфейса ClientSession. При этом на сервер передается объект HeaderSet, содержащий описание операции – PUT или GET. В результате put или get возвращают объект Operation, методом которого openOutputStream или openInputStream можно открыть соотвествующий поток вывода или ввода.

Серверная сторона, получая запрос PUT или GET, вызывает соответствующие обработчики, которые с помощью объекта Operation также работают с данными HeaderSet и создают потоки ввода или вывода информации.

Интерфейс javax.obex.ClientSession

Для создания клиентского соединения OBEX приложение использует строку определенного формата, передавая ее методу Connector.open(). Метод возвращает объект javax.obex.ClientConnection.

Для установления соединения OBEX клиент создает объект javax.obex.HeaderSet с помощью метода createHeaderSet интерфейса ClientSession.

HeaderSet createHeaderSet()

Используя объект HeaderSet, клиент может определять значения заголовка для запроса CONNECT. Пакет OBEX CONNECT также содержит число версии OBEX, флаги и максимальную длину пакета, определяемую реализацией. Для выполнения запроса CONNECT клиент передает объект HeaderSet методу connect интерфейса ClientSession.

HeaderSet connect(HeaderSet headers)

По завершении запроса заголовки OBEX, полученные от сервера, возвращаются приложению. Даже если в качестве параметра на входе не был указан объект заголовков, метод connect все равно вернет объект javax.obex.HeaderSet. Чтобы узнать, успешно ли завершился запрос, клиент вызывает метод getResponseCode интерфейса HeaderSet. Он возвращает ответный код, посылаемый сервером и определенный в классе javax.obex.ResponseCodes.

Запрос DISCONNECT выполняется так же, как и запрос CONNECT, с той лишь разницей, что вместо метода connect вызывается метод disconnect.

HeaderSet disconnect(HeaderSet headers)

Если объект javax.obex.HeaderSet содержит больше заголовков, чем возможно вместить в один пакет OBEX, то кидается исключение java.io.IOException.

Для выполнения операции SETPATH клиенту необходимо использовать метод setPath объекта ClientSession.

HeaderSet setPath(HeaderSet headers, boolean backup, boolean create)

Чтобы определить имя директории назначения, следует установить заголовок имени в требуемое назначение вызовом метода setHeader объекта HeaserSet, передаваемого методу setPath. Клиент может указать серверу, что тому следует перейти на один уровень вверх в иерархии директорий перед назначением имени, а также следует ли серверу создать директорию, если она еще не существует. Если заголовок слишком велик, чтобы быть посланным одним пакетом OBEX, кидается исключение javax.obex.IOException.

Для выполнения операций PUT или GET клиент создает объект javax.obex.HeaderSet посредством метода createHeaderSet. После определения значений заголовка вызываются методы put или get объекта javax.obex.ClientSession.

Operation get(HeaderSet headers)

Operation put(HeaderSet headers)

Реализация отправляет заголовки серверу и получает ответ. Методы put или get возвращают объект javax.obex.Operation. С его помощью клиент может определить успешность завершения запроса. В случае успешного завершения возможно отправлять или получать данные средствами потоков вывода или ввода, соответственно. По завершении операций клиентом необходимо закрывать потоки. Для отмены запросов PUT или GET через ABORT клиенту необходимо вызвать метод abort объекта javax.obex.Operation. Этот метод закрывает все потоки ввода и вывода и завершает операцию вызовом метода close объекта Operation.

Интерфейс javax.obex.SessionNotifier

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

javax.microedition.io.Connection acceptAndOpen(ServerRequestHandler handler)

Метод возвращает объект Connection, служащий для соединения с клиентом.

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

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

 

Рис.3.6. Структурная топологическая модель беспроводного соединения

 

 

Рис.3.7. Структурная топологическая модель скаттернет

3.7. Алгоритм установления соединения Bluetooth двух мобильных устройств

Клиент-серверная архитектура соединения Bluetooth предполагает выполнение ряда действий со стороны как серверной, так и клиентской части ПО.

Серверу необходимо:

1.    зарегистрировать сервис в базе данных SDDB;

2.    перейти в состояние ожидания соединения.

После этого сервер может быть обнаружен клиентскими устройствами. По запросу клиента на сервере производится поиск зарегистрированных сервисов, удовлетворяющих шаблону из одного или нескольких UUID. Если такие сервисы обнаружены, клиенту возвращаются дескрипторы (handle) найденных сервисов. Используя эти дескрипторы, клиент может получить более детальное описание сервиса, запросив значения его полей в базе данных SDDB.

Не существует механизма получения информации обо всех сервисах, зарегистрированных на конкретном сервере. Единственная возможность узнать, зарегистрирован ли определенный сервис – поиск по шаблону. Шаблон должен содержать от 1 до 12 UUID, сравниваемых с атрибутами записей сервисов.

Клиентский модуль осуществляет:

1.    поиск доступных на данный момент серверов;

2.    запрос данных о доступных сервисах, составление собственной базы (опционально);

3.    поиск нужного сервера по имеющимся данным о сервисе;

4.    запрос на соединение.

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

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

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

4. Реализация технологии построения беспроводных соединений

Изначально можно смело утверждать, что практически вся необходимая разработчику функциональность уже давно реализована в существующем интерфейсе JSR82 и нескольких SDK к нему, которые являются своего рода обкладками. Как и было задумано членами экспертной комиссии по разработке стандартов, JABWT предоставляет очень гибкий инструментарий для конструирования приложений разработчиками. Гибкость заключается в том, что представленные базовые классы и интерфейсы позволяют наладить любую форму взаимодействия модулей в рамках архитектуры «клиент-сервер». Таким образом, разработчику придется фактически из базовых элементов собирать собственную структуру приложения, что является достаточно трудоемким занятием.

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

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

4.1. Функциональность разработки

Реализация должна обеспечивать:

1.    представление клиентского и серверного модулей в форме классов;

2.    регистрацию сервиса с занесением записи в соответствующую базу данных (на серверном модуле);

3.    прием запросов от клиентов (сервер) с выдачей информации о сервисах или запуском процедуры соединения;

4.    поиск серверов с составлением перечня физических адресов (на клиентском модуле);

5.    поиск сервисов клиентом на сервере с возможностью конкретизации сведений по дополнительным запросам;

6.    соединение клиента с выбранным сервером;

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

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

9.    механизм трансформации структур данных через имплементацию общих интерфейсов;

10.корректную обработку исключительных ситуаций.

4.2. Серверный модуль

При реализации серверного модуля важно учесть ряд аспектов [12].

Серверный класс наследуется от ServerRequestHandler. Чтобы реализовать собственный механизм обработки запросов onPut и onGet, нужно перегрузить эти методы, иначе на запросы PUT и GET клиента будет возвращаться код ответа, обозначающий нереализованность соответствующих методов.

Метод onPut может выглядеть следующим образом:

public int onPut(Operation op)

{

  InputStream netStream = null;

  try

  {

    HeaderSet headers = op.getReceivedHeaders();

    netStream = op.openInputStream();

    Long fileLength = (Long)headers.getHeader(HeaderSet.LENGTH);

    byte[] buffer = new byte[fileLength];

    int read = netStream.read(buffer);

  }

  catch (IOException e)

  {

    e.printStackTrace();

  }

  finally

  {

    try

    {

      netStream.close();

    }

    catch (IOException e)

    {

      e.printStackTrace();

    }         

  }

  return ResponseCodes.OBEX_HTTP_ACCEPTED;

}

В данной реализации метода можно получить данные об объеме передаваемой информации еще в момент, когда становится доступным объект HeaderSet. Под этот объем выделяется два буфера, в первый из которых (локальный) информация попадает непосредственно из потока, а во второй (член класса) – переписывается из первого. У объекта Operation запрашивается поток ввода (InputStream). Данные из этого потока считываются до того момента, пока метод read не вернет -1. Затем происходит закрытие потока.

public int onGet(Operation op)

{

  try

  {

    HeaderSet hs2send = createHeaderSet();

    hs2send.setHeader(HeaderSet.LENGTH, new Long(sendBuffer.length));

    op.sendHeaders(hs2send);

  }

  catch(java.io.IOException e)

  {

e.printStackTrace();

  }

  DataOutputStream netStream = null;

  try

  {

    netStream = op.openDataOutputStream();

    netStream.write(sendBuffer);

    netStream.flush();

  }

  catch (IOException e)

  {

    e.printStackTrace();

  }

  finally

  {

    try

    {

      netStream.close();

    }

    catch (IOException e)

    {

      e.printStackTrace();

    }

  }

  return ResponseCodes.OBEX_HTTP_ACCEPTED; 

}

Приведенная выше реализация метода onGet создает объект HeaderSet, в который заносится объем данных, получаемых клиентом от сервера. Далее этот объект передается методу sendHeaders объекта Operation для отсылки клиенту с ближайшим сообщением OBEX. Затем создается выходной поток данных (DataOutputStream), куда методом write записывается информация из буфера. По окончании передачи поток закрывается.

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

String serviceURL ="btgoep://localhost:00B0D00154EF;name=DB_BT_OBEXServer";

В этой строке набор символов до первого знака ‘:’ обозначает протокол, по которому идет обмен данными в соединении. «btgoep» соответствует OBEX, «btspp» - протоколу SPP, «btl2cap» - протоколу L2CAP. Далее, после описания протокола, идет адрес устройства, на котором запускается сервис, и строка-идентификатор сервиса.

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

Регистрация выполняется методом open класса javax.microedition.io.Connector:

Connection clientConn = Connector.open(serviceURL);

Чтобы Bluetooth-устройство сервера могло быть обнаружено клиентами, необходимо задать режим, в котором оно будет находиться. Это делается вызовом метода setDiscoverable класса LocalDevice с соответствующим аргументом:

LocalDevice localDevice = LocalDevice.getLocalDevice();

localDevice.setDiscoverable(DiscoveryAgent.GIAC);

В качестве аргументов могут использоваться различные значения, например:

DiscoveryAgent.GIAC - устройство переходит в доступный для обнаружения режим на продолжительное время, без каких-либо условий;

DiscoveryAgent.LIAC - устройство переходит в доступный для обнаружения режим на период, определяемый каким-либо условиями или событиями;

DiscoveryAgent.NOT_DISCOVERABLE - устройство недоступно для обнаружения.

Затем, в зависимости от того, какой протокол был выбран при регистрации службы, устройство переводится в режим ожидания соединения методом acceptAndOpen:

if (clientConn instanceof SessionNotifier)

{

  SessionNotifier session = (SessionNotifier) clientConn;

  try

  {

    session.acceptAndOpen(this);

  }

  catch (IOException e)

  {

    System.err.println(e);

  }

}

Теперь при соединении с клиентом сервер будет обрабатывать запросы типа CONNECT, GET, PUT и др.

Корректное завершение работы сервера предполагает закрытие всех потоков, а также вызов метода close для объекта Connection.

4.3. Клиентский модуль

В отношении клиентского модуля также необходимо соблюсти ряд условий.

Клиентский класс должен реализовывать интерфейс DiscoveryListener. Поэтому необходимо включить в него следующие методы:

public void deviceDiscovered(RemoteDevice device, DeviceClass code)

вызывается при обнаружении устройства.

public void servicesDiscovered(int transact, ServiceRecord[] services)

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

public void serviceSearchCompleted(int transID, int responseCode)

вызывается при завершении процесса поиска служб.

public void inquiryCompleted(int discoveryType)

вызывается по завершении процесса поиска устройств.

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

public void deviceDiscovered(RemoteDevice device, DeviceClass code)

{

  startServiceDiscovery(device);

}

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

public void servicesDiscovered(int transact, ServiceRecord[] services)

{

  for (int ctr = 0; ctr < services.length; ctr++)

  {

    Connection conn = null;

    try

    {

      conn = Connector.open(services[ctr].getConnectionURL(

             ServiceRecord.NOAUTHENTICATE_NOENCRYPT, false));

      if (conn instanceof ClientSession)

        ClientSession session = (ClientSession) conn;

    }

     catch (IOException e)

    {

      e.printStackTrace();

    }

  }

}

Обработчик события обнаружения службы в приведенном коде автоматически запускает процедуру соединения с поддерживающим ее сервером. Для этого из объекта ServiceRecord методом getConnectionURL получается URL, с помощью которого методом open класса Connector инициируется процедура установления соединения.

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

UUID thatService = new UUID("00B0D00154EF ",false);

private void startServiceDiscovery(RemoteDevice device)

{

  UUID[] services = new UUID[1];

  int[] args = null;

  services[0] = thatService;

  DiscoveryAgent agent = localDevice.getDiscoveryAgent();

  try

  {

    int transaction = agent.searchServices(args, services, device, this);

    serviceSearchTransactions.put(new Integer(transaction), device);

  }

  catch (BluetoothStateException e)

  {

    e.printStackTrace();

  }

}

Обмен данными в соединении осуществляется по инициативе клиента.

Для передачи данных на сервер необходимо задать в заголовке пакета размер передаваемых данных. Это необходимо для того чтобы принимающая сторона могла узнать объем передаваемых данных еще при считывании заголовка сообщения. Для этого нужно установить значение поля HeaderSet.LENGTH. Вызов метода put, в котором передается заголовок сообщения, возвращает поток вывода, через который и производится передача данных.

public void sendData(byte[] data)

{

  DataOutputStream netStream = null;

  Operation op = null;

  try

  {

    HeaderSet headerSet = ((ClientSession)connServer).createHeaderSet();

    headerSet.setHeader(HeaderSet.LENGTH, new Long(data.length));

    op = ((ClientSession)connServer).put(headerSet);

    netStream = op.openDataOutputStream();

    netStream.write(data);

    netStream.flush();

  }

  catch (IOException e)

  {

    e.printStackTrace();

  }

  finally

  {

    try

    {

      netStream.close();

      op.close();

    }

    catch (IOException e)

    {

      e.printStackTrace();

    }

  }

}

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

public void receiveData(byte[] data)

{

  InputStream netStream = null;

  Operation op = null;

  byte[] buffer;

  try

  {

    HeaderSet headerSet = ((ClientSession)connServer).createHeaderSet();

    Operation op = ((ClientSession)connServer).get(headerSet);

    HeaderSet headers = op.getReceivedHeaders();

    netStream = op.openInputStream();

    Long fileLength = (Long)headers.getHeader(HeaderSet.LENGTH);

    buffer = new byte[fileLength];

    int read = netStream.read(buffer);

  }

  catch (IOException e)

  {

    e.printStackTrace();

  }

  finally

  {

    if (op != null)

      op.close();

    try

    {

      netStream.close();

    }

    catch (IOException e)

    {

      e.printStackTrace();

    }

  }

  data = buffer;

}

4.4. Типовой сценарий взаимодействия устройств с образованием беспроводного соединения

Сценарий построения беспроводного соединения предполагает, в соответствии с приведенным выше алгоритмом, что устройство-сервер на подготовительном этапе по протоколу SDP регистрирует запись о новом сервисе в SDDB. Эта запись содержит, помимо описывающих сервис комментариев, строку с URI, где указан протокол сервиса, сетевой адрес устройства и уникальный в рамках устройства идентификатор сервиса: "btgoep://localhost:00B0D00154EF;name=DB_BT_OBEXServer". Рекомендуется для различных по сути сервисов выбирать различные идентификаторы не только в рамках устройства, но и в масштабах всего соединения. Зарегистрировав сервис, устройство переходит в режим приема запросов от клиентов.

Устройство-клиент, обладая информацией о сервисе, который надо обнаружить, осуществляет поиск доступных в зоне охвата радио-связи устройств-серверов. В результате выполнения данной операции клиент получает список физических адресов в формате BD_ADDR – 48 бит. Далее для каждого найденного устройства-сервера проводится опрос на предмет поддерживаемых сервисов. При этом задается критерий отбора сервисов, например, уникальный идентификатор «00B0D00154EF». Получение перечня всех поддерживаемых сервисов без указания критерия поиска крайне затруднительно.

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

4.5. Требования для интеграции

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

Интеграция возможна на любой из платформ (J2ME, J2SE, J2EE), если система поддерживает интерфейс разработки приложений c использованием Bluetooth - JSR82. Когда это условие выполнено, разработчик может использовать классы серверного и клиентского модулей, реализуемые библиотекой, а также механизм трансформации структур данных к байтовому формату представления.

Для применения серверных возможностей необходимо создать экземпляр объекта класса сервера Bluetooth, вызвать метод run c указанием идентификатора сервиса. Этого достаточно, чтобы при запуске программы устройство беспроводной связи перешло в режим ожидания соединения с клиентом, предварительно зарегистрировав сервис с указанным идентификатором. Далее передача и прием данных через беспроводное соединение будут осуществляться с помощью методов серверного класса sendData и readData.

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

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

5. Практическое применение разработанных методов

При разработке программного обеспечения как части технической системы целесообразно использовать подход, изложенный в [19]. В рамках настоящей работы под проектированием понимается процесс преобразования исходного описания объекта проектирования (технического задания на разработку) в окончательное описание. При этом выполняется комплекс работ конструкторского и исследовательского характера. Работа сопровождается промежуточными описаниями – проектными решениями (например, диаграмма классов на UML). Предусмотрено выполнение следующих стадий проектирования:

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

- технический проект – выполняется всесторонняя проработка деталей реализации;

- рабочий проект – формируется необходимый набор описаний – в основном схематический.

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

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

Рис.5.1. Схема процесса проектирования

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

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

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

Проектируемая система состоит из двух модулей: клиентского (имеющего графический интерфейс для ввода данных и управления действиями по установлению соединения и передаче информации в его рамках) и серверного (осуществляющего обработку информации, получаемой от клиентских модулей, и ее отображение, возможно, также с помощью графического интерфейса). Связь между модулями поддерживается на базе технологии беспроводного соединения Bluetooth. Для его программирования применяется реализация интерфейса JSR82 на платформах J2SE или J2ME.

Графический интерфейс реализуется методами библиотеки Java Swing.

Таким образом, в конечном итоге результатом разработки станут два приложения с графическими интерфейсами на Java и возможностью установления беспроводных соединений. Они способны функционировать как на полномасштабных вычислительных системах со средой Java 2 Standard Edition, так и в рамках систем с ограниченными ресурсами в среде Java 2 Micro Edition.

5.1. Структура и функции системы

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

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

Клиент попадая в зону действия связи bluetooth (для устройств 2го класса радиус составляет до 20м, для устройств 3го – до 10м) начинает поиск доступного сервера. Затем у найденных серверов осуществляется запрос перечня поддерживаемых сервисов. Если нужная запись присутствует, клиент запускает процедуру соединения с этим сервером и передает ему данные хранящегося электронного паспорта [15].

Схема взаимодействия модулей системы приводится на следующем рисунке:

Рис.5.2. Схема взаимодействия модулей системы контроля доступа

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

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

5.2. Программно-аппаратная конфигурация

Для реализации системы не требуется передача больших объемов данных, поэтому ширины канала в 700 кбит/с вполне достаточно. Экспериментальные данные дают возможность определить интервал времени, необходимый на поиск сервера, установление связи и передачу информации – от 5 до 9 сек.

Клиентская часть системы, размещаемая на мобильном устройстве, осуществляет хранение данных паспорта в энергонезависимой памяти, а также поиск доступных серверов (порталы безопасности) и установление с ними соединений. Для этого устройство должно удовлетворять конфигурации CLDC 1.1 и профайлу MIDP 2.0 платформы J2ME. Кроме этого необходима поддержка JSR82 (Java API for Bluetooth Wireless Technology) и пакета классов javax.microedition.rms (хранение данных).

Серверная часть использует платформу J2SE, имеет графический интерфейс на основе Java Swing [5] и также использует JSR82 для работ с беспроводными соединениями (ПК оснащены usb-модулями для связи по технологии bluetooth).

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

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

В соответствии с положениями технологии Bluetooth, для установления беспроводной связи двух и более устройств необходимо осуществить ряд действий:

1.    серверная сторона регистрирует в базе данных SDDB (Service Discovery Database) запись о поддерживаемом сервисе и переходит в режим ожидания соединения с клиентом;

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

Экспериментальная идентификация была успешно осуществлена с помощью двух ПК под управлением ОС Linux Fedora Core 3, где эмулировалась конфигурация CLDC 1.1, а для установления bluetooth-соединения использовался Impronto SDK (пока JSR82 поддерживает ограниченное количество моделей мобильных устройств).

5.3. Средства разработки

Для достижения успеха в создании приложений с использованием технологии беспроводной связи Bluetooth необходимо применять соответствующий инструментарий разработки. На момент выполнения настоящей работы существовало несколько SDK, позволявших программисту реализовать механизм построения беспроводных соединений и передавать данные в их пределах. Большинство этих инструментариев имеют достаточно высокую стоимость лицензии на использование в коммерческих проектах. Однако, у некоторых компаний-разработчиков существуют программы поддержки образовательных учреждений, в рамках которых SDK предоставляется на безвозмездной основе с ознакомительными целями. Такую программу ведет Rococosoft, продвигающая пакет Impronto SDK. Этот инструментарий представляет собой библиотеку методов на java для операционных систем Linux. Использовать этот SDK вдвойне удобно, так как в конечном счете необходимо иметь приложения, способные работать в средах платформ J2SE или J2ME.

Таким образом, условием дальнейшего продолжения разработок является использование ОС семейства Linux RedHat (на этапе разработки). Кроме непосредственного применения инструментария Impronto, необходимо установить в системе средства управления аппаратными модулями Bluetooth, если таковые еще не присутствуют в системе. Для этого целесообразно выбрать пакеты инструментария BlueZ, методы которого реализуют поддержку USB-модулей беспроводных соединений, протокола регистрации сервисов SDP и протоколов передачи данных. В отличие от инструментария Impronto, поставляющегося в форме архива байткодов java-классов JAR, BlueZ доступен в виде исходных кодов на языке С, что допускает разработку без применения дополнительных SDK, однако ее результат вряд ли будет портируем на мобильные устройства в их нынешнем состоянии развития.

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

Процесс разработки включает в себя написание исходных кодов на java, их компиляцию до сбора в байткоды, отладку получаемых приложений. Для компиляции и запуска можно использовать скрипты сборки, которые обрабатывает утилита Ant. По сравнению с этим способом большим удобством обладает работа в графической среде пакета Eclipse. Фактически в нем реализованы многие технологии, делающие разработку программного обеспечения эффективной. Версии Eclipse доступны как для ОС MS Windows, так и для Linux. Среда имеет различные формы представления компонентов проекта, в том числе и древовидную структуру файлов исходных кодов, классов и др. Встроенный интерфейс отладки предоставляет программисту стандартный набор инструментов. Модуль настройки позволяет создавать различные конфигурации сборки приложения и его запуска.

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

Настройка среды операционной системы

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

- система должна корректно работать с инициализацией и открытием на прием сокетов RFCOMM. Это происходит при регистрации службы сервером протокола SDP и при последующем переходе в режим ожидания соединения с клиентом;

- программный OHCI контроллер системы должен стабильно работать с устройствами посредством портов USB в конфигурации ACPI.

Предъявление таких требований вызвано тем, что ряд версий операционных систем Linux (например, собранных на ядре 2.4.20), не удовлетворявшие им, не имели возможности выступать в качестве платформы для разработки. На них не опознавались USB адаптеры Bluetooth, а если и опознавались, то не существовало возможности поднять сервер протокола SDP и зарегистрировать службу для приема клиентских запросов.

На момент написания настоящей работы была доступна версия ядра 2.6.9 и собранная на нем ОС Fedora Core 3. Как показала проверка, эта система удовлетворяет вышеперечисленным условиям, поэтому и была избрана для использования в качестве платформы для разработки.

Проект Fedora является одним из двух наследников Red Hat Linux – другим является Red Hat Enterprise Linux. Fedora проектировался Red Hat открытым для разработчиков. Фактически, его можно считать Red Hat Linux 12. Отличия заключаются в следующем:

- проект поддерживается сообществом разработчиков – любой может к нему присоединиться при желании;

- новая версия системы публикуется каждые шесть месяцев;

- предыдущая версия поддерживается еще 6-8 месяцев после этого.

Все это означает естественное обновление системы каждые 6-8 месяцев. Если же желания обновить систему нет, вступает в действие проект Fedora Legacy – в течение полутора лет неподдерживаемым основным проектом системам разрабатываются патчи безопасности.

Официальную информацию по данной ОС можно найти в Интернет по адресу http://fedora.redhat.com/

На готовую к использованию ОС устанавливаются компоненты трех инструментариев: Impronto, Java, BlueZ. Установка ведется с помощью утилиты rpm – менеджера пакетов Red Hat. Данный менеджер поддерживает определенный формат упаковки пакетов ПО. Успех, которым он пользуется, обусловлен следующими фактами:

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

- легкость в работе по пересборке с большим количеством пакетов. Упрощается задача создания дистрибутивов из нескольких сотен инсталляционных пакетов;

- общая несложность в применении. Об этом свидетельствует большинство пользователей других версий более ранних менеджеров пакетов.

Более подробную информацию об RPM можно обнаружить по адресу в Интернет http://www.rpm.org/max-rpm/.

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

$ env

Вначале необходимо получить установочный пакет инструментария Impronto SDK и лицензию на его использование. Impronto Development Kit для Linux обеспечивает разработчикам среду Java-Bluetooth для несложного построения и внедрения приложений. Инструментарий реализует стандартный интерфейс JABWT, который был разработан экспертной группой JSR82. Поэтому следует ожидать полнофункциональной реализации методами пакетов javax.bluetooth и javax.obex положений протоколов SDP, L2CAP, OBEX и др. Зарегистрироваться и получить лицензионную копию Impronto SDK можно через Интернет по адресу http://www.rococosoft.com/registration_linux.html.

Установить пакет следует командой

# rpm –ivh impronto-1.3-1.i386.rpm

После ее успешного завершения в системные директории установлены следующие библиотеки:

/usr/lib/libimpronto.so

/usr/share/java/idev_bluez.jar

Файл лицензии на использование инструментария linuxlicense.txt размещается в директории, открытой в системной переменной

CLASSPATH=/usr/share/java

PATH=${PATH}:${CLASSPATH}

export CLASSPATH

Пакет Sun Java SDK можно загрузить с сетевого ресурса Sun. Java 2 SDK представляет собой среду разработки для сборки приложений, апплетов и компонентов, которые используют язык программирования Java. В инструментарий входят средства, необходимые для разработки и тестирования написанных на языке Java программ и выполняемых на платформе Java. В большинстве своем эти средства разработаны для использования с командной строкой и не предоставляют программисту графический интерфейс. На момент выполнения настоящей работы последнюю доступную версию инструментария можно было загрузить из Интернет по адресу http://java.sun.com/j2se/1.4.2/download.html

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

# sh j2sdk142.bin

# rpm –ivh j2sdk142.rpm

Затем следует модифицировать состав переменных окружения системы, чтобы открыть для доступа директории инструментария Java:

JAVA_HOME=/usr/java/j2sdk1.4.2_06

PATH=${PATH}:${JAVA_HOME}/bin

export PATH JAVA_HOME

Далее устанавливается пакет BlueZ для работы с протоколом SDP.

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

- полностью модульная реализация;

- безопасность работы на вычислительных устройствах с архитектурой SMP;

- многопотоковая обработка данных;

- поддержка одновременной работы с несколькими устройствами Bluetooth;

- полная абстрагированность от аппаратной базы;

- стандартный интерфейс сокетов для всех уровней;

- поддержка безопасности уровней устройства и сервисов.

К настоящему времени в BlueZ входит несколько модулей, а именно:

- подсистема ядра Bluetooth;

- уровни ядра L2CAP и SCO аудио;

- реализации ядра протоколов RFCOMM, BNEP, CMTP, HIDP;

- драйверы виртуальных устройств, HCI UART, USB, PCMCIA;

- библиотеки и демоны Bluetooth и протокола SDP;

- утилиты конфигурирования и тестирования;

- инструменты декодирования и анализа протокола.

Более подробную информацию о BlueZ можно обнаружить по адресу в Интернет http://www.bluez.org/about.html

Для установки пакета bluez-sdp необходимо выполнить команду

# rpm –ivh bluez-sdp-1.5-1.i386.rpm --force

Если принято решение использовать для сборки приложения и его запуска не среду разработки, а утилиту Ant, ее также необходимо установить.

Apache Ant это утилита сборки, основанная на использовании Java. Фактически, она похожа на Make, однако лишена связанных с ним сложностей. Подобные утилиты обычно тесно взаимодействуют с командным интерпретатором – они обрабатывают наборы зависимостей, затем выполняют команды. Расширить действие этих утилит можно путем создания программ для операционной системы, в которой идет работа. Однако, это означает привязку к самой системе или ее типу, например, Unix. Кроме этого, мейкфайлы (makefile) несут в своей структуре потенциальное неудобство – всегда можно допустить ошибку в расположении пробелов и табуляций. Этих сложностей лишена утилита Ant. Вместо модели с расширением посредством команд интерпретатора используется расширение с помощью классов Java. Работа с командами заменяется выполнением задач по древовидной структуре XML-базированного конфигурационного файла. Каждая задача выполняется объектом, который реализует конкретный интерфейс задачи. За счет этого достигается истинная кроссплатформенность. Кроме того, в распоряжении программиста, использующего утилиту Ant, имеется задача <exec>, которая предоставляет возможность выполнять команды, привязанные к типу операционной системы. Более подробную информацию об Apache Ant можно обнаружить по адресу в Интернет http://ant.apache.org/

Установка утилиты сборки производится копированием файлов поставки пакета в определенную директорию (бинарных файлов папок /bin и /lib) и публикацией одного из путей к ним в переменной среды:

ANT_HOME=/usr/local/ant

PATH=${PATH}:${ANT_HOME}/bin

export ANT_HOME

В случае, когда разработчик предпочитает утилите Ant среду разработки, например, Eclipse, следует установить и настроить последнюю. Eclipse представляет собой открытую платформу для интеграции инструментов, которая собирается открытым сообществом разработчиков инструментариев. Системы, основанные на Eclipse, обеспечивают разработчикам свободу выбора языка программирования, платформы и среды разработки. Имеется оболочка (framework) для плагинов, позволяющая создавать, интегрировать и задействовать различные инструменты без каких бы то ни было проблем. Платформа Eclipse написана на языке Java и поставляется с набором инструментариев разработки плагинов и соответствующими примерами. Более подробную информацию об этом проекте можно получить в Интернет по адресу http://www.eclipse.org

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

6. Заключение

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

Благодаря гибкости, которой обладают рассмотренные программные компоненты платформы Java 2 Micro Edition, их можно применять для решения очень большого круга задач. В частности в него входит и задача контроля доступа, рассмотренная выше. Пример разработки подобного приложения несет информацию не только о том, как программно управлять беспроводной связью в Linux.

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

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

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

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

В настоящий момент полностью освоена и используется за некоторыми изменениями технология построения беспроводных соединений посредством Bluetooth. Однако, отсутствуют какие либо препятствия для использования разрабатываемой математической модели с другими видами радиосвязи, такими как WiFi или WiMAX. В частности, успешное использование этих видов связи на платформе Windows Mobile гарантируется применением технологии сокетов в приложениях, разрабатываемых для .NET [3].

В общем случае предполагается применение технологии Bluetooth на базе платформы Java 2 Micro Edition (как наиболее распространенных среди различных моделей мобильных устройств). Для корректного функционирования программной реализации необходима поддержка интерфейса JSR-82 операционной системой устройства. Данный интерфейс обеспечивает функционирование всех необходимых протоколов – SDP для работы с сервисами, RFCOMM, L2CAP и OBEX для обмена данными. Тогда будет иметь место следующий вариант распределения функций между клиентскими и серверными модулями. Серверы, предоставляющие клиентам свои аппаратные ресурсы для проведения распределенных вычислений, вначале регистрируют в специализированной базе данных запись о поддерживаемом сервисе. По этой записи клиент определяет, что с тем или иным сервером возможно проводить распределенные операции. После регистрации сервиса сервер переходит в режим ожидания соединения с клиентом. Работа в данном режиме проходит «в фоне», т.е. не мешает функционированию других задач устройства. Клиенты, заранее имеющие информацию, какой сервис надо искать на серверах для проведения распределенных вычислений на их ресурсах, осуществляют поиск доступных серверов, поиск на них необходимого сервиса и в случае его успешного завершения инициируют процедуру установления соединения.

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

На этой схеме блоки операций разделяются на две группы. Ряд операций (блоки на белом фоне) выполняется непосредственно с целью обмена информацией по беспроводному соединению. Они исследованы экспериментально. Остальные действия (блоки на затемненном фоне) связаны с функционированием модели. Их реализация планируется.

Аппаратная часть базы для верификации разрабатываемой модели включает в себя несколько платформ. Непосредственно в рамках исследований используется ПК 32-битной архитектуры х86. Наиболее широкие возможности для сопровождающих эксперименты разработки и отладки предоставляет конфигурация установки под управлением операционной системы Linux (на ядре 2.6.9 и более новом) с установленными компонентами программирования Sun Java, Rococosoft Impronto, BlueZ и пакетом для проведения параллельных вычислений, например, JMPI. В этом случае среда мобильного устройства эмулируется, возможность работы с беспроводной связью обеспечивается с помощью соответствующих адаптеров, например, для технологии Bluetooth через порт USB.

Условия, более близкие к естественным, для проведения экспериментов создаются установкой предварительно отлаженного программного обеспечения на мобильное устройство, например, сотовый телефон. В этом случае необходима как аппаратная, так и программная поддержка устройством формата приложения на Java и технологии беспроводной связи. В отличие от экспериментальной установки ПК такие конфигурации организуются не на базе платформы Java 2 Standard Edition, а с помощью Java 2 Micro Edition.

Рис.6.1. Схема взаимодействия клиентского и серверного модулей системы распределенных вычислений

В двух вышеописанных случаях исследования приложения для мобильного устройства используются приблизительно одинаковые настройки программной среды – это конфигурация CLDC 1.1 и профайл MIDP 2.0. Они определяют необходимый набор классов, который обеспечивает требуемую функциональность приложения на Java. Поддержка беспроводных соединений Bluetooth осуществляется при наличии интерфейса JSR-82.

Альтернативу экспериментальным установкам на платформах Java может составить конфигурация под управлением MS Windows Mobile. В этом случае разработка и отладка выполняются средствами технологий .NET.

 

Список литературы

[1] Attiya H., Welch J. Distributed Computing. Wiley, 2004.

[2] Bluetooth Specification v.2.0 + EDR. Bluetooth SIG, 2005.

[3] Boling D. Programming Microsoft Windows CE .NET. Microsoft Press, 2003.

[4] CLDC Specification, v.1.1, Sun Microsystems, 2003.

[5] Eckstein R., Loy M., Wood D. Java Swing. O`Reilly & Associates, 1998.

[6] Farley J. Java Distributed Computing. O`Reilly, 1998.

[7] Harold E.R. Java Network Programming. O`Reilly, 2004.

[8] Kirkhus L., Sveen A. An examination of mobile devices for spontaneous collaboration. Norwegian University of Science and Technology, 2003.

[9] McCall D. Taking a Walk Inside Bluetooth EDR. CommsDesign, 2006.

[10] Mobile WiMAX – Part I : A Technical Overview and Perfomance Evaluation. WiMAX Forum, 2006.

[11] Беломойцев Д.Е. Система контроля доступа по беспроводной связи для мобильных телефонов. Конференция «Технологии Microsoft в теории и практике программирования». 2005.

[12] Беломойцев Д. Разработка приложений на основе Bluetooth API (JSR82). Часть I: Знакомство с Bluetooth на платформе J2ME. RSDN-Magazine #1-2005.

[13] Васильев А. Избавление от проводов. Hard`n`Soft #12(90)-2001.

[14] Воеводин В., Воеводин Вл. Параллельные вычисления. СПб.: BHV-СПб, 2002.

[15] Волосатова Т.М., Чичварин Н.В., Беломойцев Д.Е. GPS-навигация и контроль доступа в пикосетях мобильных телефонов. Международный симпозиум «Образование через науку». 2005.

[16] Кессених В., Иванов Е., Кондрашов З. Bluetooth: Принципы построения и функционирования. Chip News. 2001. № 7.

[17] Корнеев В. Параллельные вычислительные системы. М.: Нолидж, 1999.

[18] Нанс Б. Компьютерные сети. Пеp. с англ. М.: Бином, 1996.

[19] Норенков И.П. Системы автоматизированного проектирования: Кн.1. Принципы построения и структура. М.: Высш. шк., 1986.

[20] Норенков И.П., Трудоношин В.А. Телекоммуникационные технологии и сети. –М.: Изд-во МГТУ им.Н.Э.Баумана, 2000.

[21] Прикладные информационные системы контроля, управления и навигации аэрокосмич. объектов: Сборник / Гл. ред. Норенков И.П. - М., 2001.

[22] Протоколы информационно-вычислительных сетей / Под ред. И.А.Мизина, А.П.Кулешова. М.: Радио и связь, 1990.

[23] Топорков В. Модели распределенных вычислений. М.: Физматлит, 2004.

[24] Шатт С. Мир компьютерных сетей / Пер. с англ. К.: BHV, 1996.

 

 

 

 

Приложение 1. Конфигурации и профайлы

 

 

 

 

Таблица 3.1. Конфигурации J2ME

Конфигурация	Устройства	Характеристики устройств	Вирт. машина
Connected Limited Device Configuration	Мобильные телефоны, КПК, дуплексные пейджеры	1.   от 160KB до 512KB для рантайма java	KVM
Connected Device Configuration	Встраиваемые устройства, цифровые телевизоры, приставки, органайзеры, смартфоны и коммуникаторы	1.   минимум 512KB ROM 2.   минимум 256KB RAM	CVM

 

 

 

 

 

 

Таблица 3.2. Профайлы J2ME

Профайл	Характеристики устройств	Функции	База
Профайл MIDP	1.   128 KB для компонентов MIDP 2.   8 KB для перманентной Java 3.   32 KB для рантайма Java 4.   Соединение с сетью	Профайл для дуплексных пейджеров, мобильных телефонов и других устройств с узкоканальными сетевыми соединениями.	CLDC, спецификация  JSR37
Профайл PDA	5.   512 KB памяти всего (ROM + RAM), доступной для рантайма Java и библиотек, менее 16 MB	Профайл для использования в носимых устройствах – КПК.	CLDC. Спецификация JSR75.
Профайл Foundation	6.   512 KB минимум RAM 7.   1 MB минимум ROM 8.   Соединение с сетью	-	CDC.  Спецификация JSR46
Профайл Personal Basis	9.   1 MB минимум RAM 10. 2 MB минимум ROM 11. Устойчивое соединение с сетью	Предоставляет базовые возможности GUI для устройств типа цифровых телевизоров, автомобильных навигаторов. Также является базой для профайла Personal.	Профайл Foundation (CDC). Спецификация JSR129.
Профайл Personal	12. 2.5 MB минимум ROM 13. 1 MB минимум RAM 14. Устойчивое соединение с сетью	Для использования в устройствах с высокой степенью Web-совместимости, например, для запуска стандартных Java апплетов. Заявлен следующим поколением сред PersonalJava .	Профайл Foundation (CDC). Спецификация JSR62.
Профайл RMI	15. 2.5 MB минимум ROM 16. 1 MB минимум RAM 17. Сеть TCP/IP	Предоставляет возможности RMI.	Профайл Foundation (CDC). Спецификация JSR66.
Профайл Game	-	Обеспечивает базу для разработки игровых приложений на платформе Java.	Профайл Foundation (CDC) или J2SE. Спецификация JSR134.

 

 

Приложение 2. Клиентский и серверный конечные автоматы

 

Рис.3.8. Конечный автомат клиентского модуля

 

Рис.3.9. Конечный автомат серверного модуля