Lokalfunk

Unter Linux ist es dank des BlueZ Bluetooth Protocol Stack und den bluez-utils (Standardpackage bei ubuntu), sowie der Library OpenObex schon auf der Kommandozeile recht einfach möglich, mit Bluetooth zu experimentieren und z.B. Dateien per OBEX an Mobilgeräte zu versenden.

Die wichtigsten Befehle sind:

• hcitool: bluez-utils; Device Inquiry (Suchen von BT-Geräten in der Nähe); Verbindungsaufbau; Manpage
• sdptool: bluez-utils; Service Discovery (Dienste auf dem entfernten Gerät erkennen); Manpage
• obexftp: OpenObex; Obex FTP und auch Push; Manpage

Einige Beispiele:

• Mit hcitool inq führt eine Device Inquiry durch. Dies ist die Voraussetzung für alle weiteren Aktionen, insbesondere wird die Bluetooth Adresse (i.F.: **BT-ADR**) benötigt.
• sdptool browse **BT-ADR** führt daraufhin eine Service Discovery durch, mit der man z.B. erfährt, ob das entfernte Geräte Obex Push unterstützt.
• hcitool cc **BT-ADR** baut eine Verbindung zum BT-Gerät der Wahl auf.
• Danach kann periodisch die Entfernung zum Geräte per RSSI (Radio Signal Strength Indicator) abgefragt werden: hcitool rssi **BT-ADR**. Das “Mapping” von Rückgabewerten zu Entfernung in Metern ist dabei allerdings stark von der Umgebung abhängig und nur möglich, solange eine Verbindung zum BT-Partner besteht.
• Schließlich lässt sich per obexftp -b **BT-ADR** -U none -H -B **PUSH-CHANNEL** -p **FILE** eine lokale Datei (**FILE**) per Obex-Push versenden. Den Push-Channel erhält man aus der Rückgabe der Service Discovery, z.B. per Regexp: /0x1105[\W\w\n]*?Channel:\s(\d{1,2})/g

Update:
Unter http://www.chaostal.de/cgi-bin/parser.cgi?input=article/bluetooth gibt es gute weiterführende Infos zu Bluetooth-Tools unter Linux (Danke an Florian H. für den Tipp!)

In einem der ersten Posts habe ich eine mögliche Architektur eines lokalen Bluetooth-Informationssystems skizziert. Grundlage ist dabei eine mehr oder weniger dauerhafte Verbindung zwischen den Transmittern (WLAN/Bluetooth …) und einem zentralen Distributionsserver, der z.B. die zu versendenden Daten liefert und die Downloads zentral loggt.

Eine interessante Eigenschaft von Bluetooth ist nun aber, dass spontane Netzwerke möglich werden, d.h. es verbinden sich mehrere Kommunikationspartner spontan für einen begrenzten Zeitraum und meistens um eine bestimmte Aufgabe zu erfüllen. Im Gegensatz zu “klassischen” Netzwerken müssen sie wenig übereinander wissen, die Einzelheiten der Kommunikation (Protokoll, Geschwindigkeit, Authentifizierung,…) werden ad hoc durchgeführt. Die Herausforderung liegen dabei vor allem in der Sicherstellung von Dienstqualität, denn der Absender einer Nachricht weiß zunächst nicht mit Sicherheit, wann oder ob überhaupt die Nachricht den Empfänger erreicht und ob der überhaupt etwas damit anfangen kann.

Im Falle des zuvor skizzierten Bluetooth Informationssystems liessen sich zwei “Ausbaustufen” denken:

1. Transmitter werden nicht direkt mit dem Distributionsserver verbunden, sondern verbinden sich spontan mit einem anderen Transmitter, der wiederum entweder mit dem Distributionsserver oder mit einem anderen Transmitter verbunden ist (in der Grafik: Server + Sender + Sender Gateway):

   

   Alle Kommunikationsteilnehmer implementieren eine Form von Routing und teilen das Wissen um bestimmte (asynchrone) Nachrichtentypen.

2. In einem weiteren Schritt werden auch mobile Endgeräte mit einbezogen und können als autonome Transmitter agieren. Dafür würde eine spezielle Software auf den Endgeräten benötigt.

Der Vorteil eines Netzes wie unter 1. ist z.B. konkret im Kontext Bluetooth Marketing in der einfachen Bedienung und Flexibilität zu finden: Einzelne Transmitter in einem räumlich begrenzten Bereich (z.B. Messe, Konzertsaal) müssen nicht alle über Mobilfunk oder Ethernet mit dem zentralen Server verbunden werden. Dies spart Aufwände im Aufbau und Verbindungskosten. Außerdem erlaubt es den Dienst auch in Räumen anzubieten, die schwer oder gar nicht mit Kabeln zu versehen sind.

Ein anderer Anwendungsfall ist die Kombination von mobilen Transmittern (z.B. bei Promotionteams) und dem “fest” installierten System. Die mobilen Transmitter gleichen sich spontan mit vereinzelt angebrachten, “stationären” Transmittern ab.

Einen Entwurf für eine Anwendung wie unter 1. beschrieben biete ich hier unter dem Titel “Entwurf zur Kommunikation und Synchronisation in lokalen Funk -Informationssystemen: Distributed Local Network” an und würde mich über Feedback freuen, auch z.B. wenn jemandem bereits ein ähnliches System (produktiv oder im Entwurf) bekannt ist.

Nokia ist, soweit ich weiß, der erste und momentan einzige Telefon-Hersteller, der ein NFC Gerät im Portfolio hat. Wie so oft sind die Finnen sehr weit vorne, wenn es um innovative Funktechnologien geht (s.a. Bluetooth Entwicklung und sehr frühe WLAN-Integration). Es handelt sich dabei um das Series 40 Gerät 6131 NFC:

With Nokia 6131 NFC phone you can have your credit card, travel card and loyalty card in your phone and use it as a multi-purpose smart card.
…
The Nokia 6131 NFC supports JSR 257 for 3rd party NFC application developers.

(auf forum.nokia.com)

Die JSR 257 (Contactless Communication API) und das entsprechende SDK von Nokia erlauben jetzt die Entwicklung von NFC-Anwendungen bequem aus J2ME (Java) heraus.

Ein NFC spezifisches Blog mit einigen interessanten Einträgen für NFC Entwickler oder solche die es werden wollen ist http://www.nfc-development.org/, leider scheint dort in der letzten Zeit nicht soviel zu passieren, ich hoffe auf mehr.

(Bildquelle: Nokia)

Eine weitere, sehr feine Sache, gerade wenn man beginnt, sich mit Bluetooth Programmierung auf Mobiltelefonen zu beschäftigen ist der BT-Browser auf Benhui.net.

Diesen Code ausprobieren und nachvollziehen, dann weiss man alles Wichtige.

Eine andere gute Idee wäre die Benhui.net Bluetooth Datenbank, die für Bluetooth-Mobiltelefone die Ergebnisse der Service Discovery bereitstellen soll. Leider ist der Zugriff seit langer Zeit nicht möglich.

Wer schon mal vor der Frage stand, wie in aller Welt man Tausende von Mobiltelefontypen, alle mit ihren Eigenheiten, in eine Datenbank bekommt und ständig pflegt, um damit ein WAP Portal oder ein wenig Bluetooth Marketing und Blueprinting aufzubauen, der kann wirklich abschätzen, was WURFL für die Entwicklung von Mobile Marketing - Systemen bedeutet.
Aber was ist das?

The WURFL is an XML configuration file which contains information about capabilities and features of many mobile devices.
The main scope of the file is to collect as much information as we can about all the existing mobile devices that access WAP pages so that developers will be able to build better applications and better services for the users.

Das heisst, mit dieser frei verfügbaren XML-Datenbank und den freien APIs in diversen Programmiersprachen kann zu fast jedem Mobiltelefon ermittelt werden, welche Features es besitzt (mp3,avi,E-Mail,WLAN,MMS, und viele viele Daten mehr). Die meisten Handy-Webportale und vor allem Hersteller von Marketing Systemen nutzen diese verlässlichen Daten, so auch die Firma exozet, die für die Wall AG die Bluetooth Marketing Software entwickelt hat und WURFL für die Auswahl der korrekten Inhalte in einer Bluetooth Kommunikation verwendet.
Ich konnte mich in einem Projekt auch selbst von der einfachen Integrationsmöglichkeit über die WURFL-Java API überzeugen.

Open Source Software und freie, verlässliche, umfassende Datenbank im Kontext (Mobile-) Marketing, das ist fast unheimlich, aber vor allem: wahnsinnig nützlich.

Zum Schluß noch ein kleiner Ausschnitt aus der Wurfl-XML Datei:

<device user_agent="Nokia6061" actual_device_root="true"
   fall_back="nokia_generic_series40_dp20" id="nokia_6061_ver1">
<group id="product_info">
	<capability name="model_name" value="6061"/>
</group>
<group id="display">
	<capability name="resolution_height" value="160"/>
	<capability name="max_image_height" value="128"/>
</group>
<group id="image_format">
	<capability name="colors" value="65536"/>
</group>
<group id="object_download">
	<capability name="ringtone_amr" value="true"/>
	<capability name="ringtone_awb" value="true"/>
	<capability name="ringtone_mp3" value="true"/>
	<capability name="ringtone_voices" value="16"/>
</group>
<group id="j2me">
	<capability name="j2me_screen_height" value="160"/>
</group>

Wieder bei golem.de steht heute die Meldung, dass Nokia für Juni diesen Jahres eine neue Entwicklungsumgebung für die Series 40 5th. Edition herausbringen will. Nokia Series 40 Geräte laufen auf dem Nokia eigenen Betriebssystem, stellen die größte Anzahl innerhalb der Baureihen (Series 60,80,90 usw.) und darunter fallen praktisch alle “günstigeren” Telefone. Interessant ist, dass nun endlich auch die Bluetooth Java API (JSR82) in die Series 40 Einzug halten soll. Dies passiert im Rahmen des Spezifierungsprozeßes JSR248, Meldung dazu bei areamobile.de, der auch eine Kapselung von bisher eigenständigen J2ME APIs bringt, d.h. man sollte davon ausgehen, dass JSR 248 spezifizierte Geräte folgende APIs unterstützen (Liste zit. bei areamobile.de):

• JSR-184 (Mobile 3D Graphics API) in Version 1.1
• JSR-179 (Location API) für lokalisierte Dienste
• JSR-177 (SATSA) für Sicherheitsfunktionen und Zertifikatsverwaltung
• JSR-180 (SIP API) fürs Session Initiated Protocol, das beispielsweise VoIP-Anwendungen ermöglicht
• JSR-211 (Content Handler API) für die Verwaltung von Applikationen, mit denen sich bestimmte MIME-Typen öffnen lassen
• JSR-226 (Scalable 2D Vector Graphics) für die Darstellung von SVGtiny-Inhalten
• JSR-229 (Payment API)
• JSR-238 (Internationalization API) für die Lokalisierung von Java-Applikationen
• JSR-205 (Messaging)
• JSR-172 (Web Services)
• JSR-135 (Mobile Media)
• JSR-82 (Bluetooth)
• JSR-75 (File&PIM)

Das wäre ein wichtiger Schritt für die Entwicklung von Lokalfunk- / Location Based Services Anwendungen auch auf Einsteigergeräten.
Ohne jetzt auf die Einzelheiten einzugehen, erst mit JSR-82 (Bluetooth) ist anwendungsbasierte Bluetooth-Kommunikation möglich,
hinzukommen die File API (JST-75), die praktischerweise z.B. das Speichern von über Bluetooth geladenen Inhalten erlaubt und Content Handler die die dann auch anzeigen lassen können. Dies dann plattformübergreifend, mit einer funktionierenden Location API (Auswertung von GPS-Daten / Funkzellenortung), sinnvollen WebServices und Payment kombiniert ist eine spannende Basis für echte Pull-Informationsdienste mit massenweise OptIns / OptOuts und Sicherheitsmechanismen.
Nimmt man dazu noch sinkende Verbindungspreise und GPS könnten Location Based Services bald wirklich interessant werden. Nun ja, falls den Mobilfunknetzbetreibern nicht noch was “Nettes” einfällt.