Package Bundles The following subsections give beside the requirements of such a device and the structure of API architecture, views into the necessary configuration of services and devi
Trang 1Fig 6 Screenshot Wireless Toolkit: Selection of APIs
4.1 Configurations and Profiles
Since not all characteristics of all devices are known it is difficult to create a run time
environment that fits to all characteristics of the different devices Therefore one pursues the
approach of configurations within the Java Micro Edition A certain number of devices is
assigned to a configuration according to their efficiency Like that those programs are run
able on all devices that have this configuration The partitioning in CLDC and CDC
configuration is made as in the previous section Fig 7 shows the architecture of a CLDC
configuration with the MID Profile like it is used for mobile applications Because of the
rapid development and the short life cycle of such devices it is not possible to specify all
variants Therefore additional native applications, running direct on the operating system,
and manufacturer-specific Java classes and applications are used
Native Applications
MIDP Manufacturer-specific Applications
MIDP CLDC with KVM Operation System
Hardware Fig 7 Architecture of the CLDC
The following table shows an overview of at present available configurations of Java ME Regarding to the technological development of the mobile devices with the CLDC 1.1 compared to its previous version 1.0 the minimum necessary memory was increased from
160 to 192 KB The main reason for it was the introduction of the classes Float and Double Further smaller errors were corrected and some additional classes were added It might be only a question of time until all mobile devices support version 1.1 of the configuration, but
at the moment one has to consider which version the current hardware supports
Table 2 Java ME Configurations The CDC configuration contains a substantially larger part of the Standard Edition APIs And the appropriate Foundation Profile contains the entire Java Abstract Window Toolkit (AWT) with all functions necessary for executing Java Applets The Personal Basis Profile is
a subset of the Personal Profile and makes available nuclear functionality with a minimum graphic support Here is not dealt with CDC and their profiles, since for the for the mobile application development the CLDC is crucial
The optional packages can be merged depending upon the needs of the application and the hardware requirements Following table shows an excerpt of the most important Packages
Trang 2with their JSRs numbers All JSRs can be looked up under www.jcp.org the homepage of the
Java Community Process, under the direction of Sun
Table 4 Optional Packages
Following table gives an overview of the spreading specifications The Mobile Service
Architecture specification (MSA) JSR 248 refers like its predecessor JSR 185 to a large extent
of already existing specifications It eliminates ambiguity and gives supplementing data
where it is necessary A goal of these spreading specifications should be to prevent a
splintering of the individual APIs and give the different hardware manufacturers a
guideline for the smallest common denominator A device which fulfills the MSA
specification must at least fulfill the MSA Subset, which is a subset of the MSA with
decreased function range An overview of the function range and the pertinent JSRs of the
MSA and MSA Subset specification give Fig 8 A minimum requirement to the hardware of
the devices is also defined by the MSA specification At least 1024 KB of volatile memory, a
screen size of at least 128x128 pixels with a depth of shade of 16 bits A multiplicity of
further requirements can be inferred from the documentation JSR 248
Table 5 Package Bundles
The following subsections give beside the requirements of such a device and the structure of API architecture, views into the necessary configuration of services and devices and the general operational sequence of Java ME based Bluetooth communication under consideration of all security aspects
Requirements:
For the employment of the JSR 82 API on mobile devices at least 512 KB main memory are needed, as well as a complete implementation of the Java ME CLDC version 1.0 In addition the existing Bluetooth hardware must exhibit a qualification of the Bluetooth Qualification Program at least for the profiles GAP, SDAP and SPP Further the SDP, RFCOMM and the L2CAP profiles must be supported and accessibility for the API of these protocol layers must exist
The access on the lower hardware and protocol layers is administered of a so-called Bluetooth Control Centre (BCC) Therefore it is not a component of the API, and must be provided by the hardware environment
If all requirements are fulfilled, the Bluetooth API offers the following features during the application development:
- Registration of services
- Inquiry search of Bluetooth hardware and services
- RFCOMM, L2CAP and OBEX connections between Bluetooth devices
Trang 3with their JSRs numbers All JSRs can be looked up under www.jcp.org the homepage of the
Java Community Process, under the direction of Sun
Table 4 Optional Packages
Following table gives an overview of the spreading specifications The Mobile Service
Architecture specification (MSA) JSR 248 refers like its predecessor JSR 185 to a large extent
of already existing specifications It eliminates ambiguity and gives supplementing data
where it is necessary A goal of these spreading specifications should be to prevent a
splintering of the individual APIs and give the different hardware manufacturers a
guideline for the smallest common denominator A device which fulfills the MSA
specification must at least fulfill the MSA Subset, which is a subset of the MSA with
decreased function range An overview of the function range and the pertinent JSRs of the
MSA and MSA Subset specification give Fig 8 A minimum requirement to the hardware of
the devices is also defined by the MSA specification At least 1024 KB of volatile memory, a
screen size of at least 128x128 pixels with a depth of shade of 16 bits A multiplicity of
further requirements can be inferred from the documentation JSR 248
Table 5 Package Bundles
The following subsections give beside the requirements of such a device and the structure of API architecture, views into the necessary configuration of services and devices and the general operational sequence of Java ME based Bluetooth communication under consideration of all security aspects
Requirements:
For the employment of the JSR 82 API on mobile devices at least 512 KB main memory are needed, as well as a complete implementation of the Java ME CLDC version 1.0 In addition the existing Bluetooth hardware must exhibit a qualification of the Bluetooth Qualification Program at least for the profiles GAP, SDAP and SPP Further the SDP, RFCOMM and the L2CAP profiles must be supported and accessibility for the API of these protocol layers must exist
The access on the lower hardware and protocol layers is administered of a so-called Bluetooth Control Centre (BCC) Therefore it is not a component of the API, and must be provided by the hardware environment
If all requirements are fulfilled, the Bluetooth API offers the following features during the application development:
- Registration of services
- Inquiry search of Bluetooth hardware and services
- RFCOMM, L2CAP and OBEX connections between Bluetooth devices
Trang 4- Transmission of data, excluded voice connections
- Administration and controlling of communication connections
- Security mechanisms for expiration of communication
Here it is pointed out that the presence of Bluetooth and Java on mobile devices does not
guarantee the support of the JSR 82 API, since among other things the possibilities of a
device configuration are reduced by the Java ME However this applies only to a part of the
mobile phones offered nowadays
Structure of API architecture:
The JABWT APIs extends the MIDP 2.0 platform with Bluetooth and OBEX support and
consists of two packages, the fundamental Bluetooth API javax.bluetooth and the
OBEX API javax.obex Both are dependent on the package javax.microedition.io, which
belongs to the CLDC, and optionally applicable depending upon requirements of the
application Fig 9 clarifies the position of the Bluetooth API within an CLDC MIDP
environment
Fig 9 Bluetooth in the Java Architecture
A Bluetooth application can be divided first into five ranges, which are processed with an
implementation in chronological order: Stack initialization, management of devices, finding
devices, finding services and communication All APIs needed for these are part of the
javax.bluetooth package
As was already described on the basis the SDP, Bluetooth devices can take the role of a
server or a client This is specified in each case by the application The activity diagram from
following Fig 10 gives an overview of the individual fields of server and client
Fig 10 Client and Server Activities
The initialization of the Bluetooth stack is independently of their operational area necessary for each Bluetooth application A client application contains the search for devices and services, as well as the connection establishment with devices resulting from it and a following service use A server application makes services available, administers these and reacts on connecting inquiries
4.3 JSR 120 and JSR 205
A further Java API for the mobile communication is the Wireless Messaging API (WMA) The versions 1.0 and 1.1 were published in the JSR 120 (JCP, 2003) version 2.0 in the JSR 205 (JCP, 2004) With the Wireless Messaging API a mobile application can react on SMS and MMS messages, which are addressed to a certain port of the mobile phone, to which the application has registered itself, and process the received data Messages also SMS in a binary format can be processed beside simple text or multimedia messages
For further data communication in mobile communication networks as for example GPRS or UMTS further APIs are not necessary, since it concerns packet-oriented networks here and
Trang 5- Transmission of data, excluded voice connections
- Administration and controlling of communication connections
- Security mechanisms for expiration of communication
Here it is pointed out that the presence of Bluetooth and Java on mobile devices does not
guarantee the support of the JSR 82 API, since among other things the possibilities of a
device configuration are reduced by the Java ME However this applies only to a part of the
mobile phones offered nowadays
Structure of API architecture:
The JABWT APIs extends the MIDP 2.0 platform with Bluetooth and OBEX support and
consists of two packages, the fundamental Bluetooth API javax.bluetooth and the
OBEX API javax.obex Both are dependent on the package javax.microedition.io, which
belongs to the CLDC, and optionally applicable depending upon requirements of the
application Fig 9 clarifies the position of the Bluetooth API within an CLDC MIDP
environment
Fig 9 Bluetooth in the Java Architecture
A Bluetooth application can be divided first into five ranges, which are processed with an
implementation in chronological order: Stack initialization, management of devices, finding
devices, finding services and communication All APIs needed for these are part of the
javax.bluetooth package
As was already described on the basis the SDP, Bluetooth devices can take the role of a
server or a client This is specified in each case by the application The activity diagram from
following Fig 10 gives an overview of the individual fields of server and client
Fig 10 Client and Server Activities
The initialization of the Bluetooth stack is independently of their operational area necessary for each Bluetooth application A client application contains the search for devices and services, as well as the connection establishment with devices resulting from it and a following service use A server application makes services available, administers these and reacts on connecting inquiries
4.3 JSR 120 and JSR 205
A further Java API for the mobile communication is the Wireless Messaging API (WMA) The versions 1.0 and 1.1 were published in the JSR 120 (JCP, 2003) version 2.0 in the JSR 205 (JCP, 2004) With the Wireless Messaging API a mobile application can react on SMS and MMS messages, which are addressed to a certain port of the mobile phone, to which the application has registered itself, and process the received data Messages also SMS in a binary format can be processed beside simple text or multimedia messages
For further data communication in mobile communication networks as for example GPRS or UMTS further APIs are not necessary, since it concerns packet-oriented networks here and
Trang 6so each mobile phone is IP addressable The operating system usually makes this connection
and administers it From application view the standard APIs for Socket or HTTP
communication can be used It is the same procedure like in WLAN networks
4.4 MIDlet
A Java program which was written for the MID profile is called to MIDlet; one or more
MIDlets can be combined in a MIDlet Suite After compiling source code one has a jad and a
jar file, which can be loaded on a mobile phone afterwards Each device on which a MIDlet
should be executed must provide an environment which guarantees execution and
administration of MIDlets This environment is called Application Management Software
(AMS) and controls the life cycle of the MIDlets A MIDlet can be like the well-known Java
Applet also only in one of three states Between the two states Paused and Active the MIDlet
can change during its runtime The state Destroyed is however final The MIDlet can even
change its states by the help of special methods, but must notify the AMS about it The AMS
can change the states of the MIDlets at any time This can happen if the resources of the
MIDlets are needed by other processes, for example in case of a incoming telephone call the
AMS sets the MIDlet into state Paused and the necessary display is used for the telephone
call
The MIDlet object is generated by the AMS and is first in the state Paused see Fig 11, thus
still no resources are blocked Afterwards the MIDlet is started by the AMS through a call of
the method startApp() Now the MIDlet is in state Active and all needed resources will
be requested From the state Active the MIDlet can change again into the state Paused
through the AMS or by itself If for example a telephone call arrives the AMS sets the MIDlet
into state Paused, since it needs some resources like for example the display of the MIDlet
The MIDlet asks periodically with the method resumeRequest() if it is allowed to run
again, in this case the AMS starts the MIDlet by means of the method startApp()
Fig 11 State diagram of a MIDlet
From the state Active the MIDlet can be set by itself or by the AMS into state Destroyed It
releases then all requested resources and stores if necessary application data for the further
use Afterwards the MIDlet can be eliminated by the Garbage Collector
4.5 Application Deployment
The occasionally complex installation was a big obstacle in the past which prevented a wide spreading of mobile applications Usually for this a PC with for the mobile phone suitable configuration software was necessary, with which the mobile phone was connected by a data cable For mobile Java applications there is another further alternative, which is favored
in particular by the mobile games market Here the installation of new MIDlets is at any time at each place within shortest time possible, always when the user needs certain programs for its mobile phone This is reached by the download of the desired MIDlet over
a UMTS or a GPRS connection The necessary URL for this receives the user either from the browser of the mobile phone or by SMS In addition such a call is also directly possible from
a MIDlet The development of specialized Part-MIDlets, for example for different equipment variants of a vehicle, is now possible which are downloaded on demand directly to the user's mobile phone
The protocol for such a Over The Air (OTA) transmission is HTTP Communication over HTTP is a firm component of MIDP and thus the standard technique for the data communication of MIDlets The support of further protocols is however optional In addition MIDlets offer with the method platformRequest(string URL) a standard procedure for the download of new programs over a HTTP connection
Apart from the MIDP specification the optional content Handler API (JSR 211) contains also this functionality Duty of the content Handler API is actually to pass certain tasks to other programs For example playing music at the on the mobile phone installed media player However it can be also used to download and to install new programs on the device With this kind of installation the appropriate jad and jar file must be on a web server reachable for the mobile device In the jad file thereby to the location of the jar file is referred
4.6 Security
In MIDP there is an extensive security concept, which on the public key procedure for the verification and authentication of MIDlet Suites is based This security concept serves the preventing of, the use of sensitive operations, like for example the establishment of a expensive network connection, without preventing the knowledge of the user So that a signed MIDlet can get access to a sensitive API, the appropriate permission must be set This permission is indicated in the jad file
In MIDP there are so-called Protection Domains which MIDlets are assigned to In the Protection Domains is specified how to deal with the permissions
There are the following Protection Domains:
minimum: MIDlets of these Protection Domain, access to all Permissions is refused
untrusted: The user must give his agreement with each call to an API proteceted by a Permission of these Protection Domain This is the default domain for unsigned MIDlets
trusted/maximum: The access to all Permissions of this Protection Domain is permitted
Trang 7so each mobile phone is IP addressable The operating system usually makes this connection
and administers it From application view the standard APIs for Socket or HTTP
communication can be used It is the same procedure like in WLAN networks
4.4 MIDlet
A Java program which was written for the MID profile is called to MIDlet; one or more
MIDlets can be combined in a MIDlet Suite After compiling source code one has a jad and a
jar file, which can be loaded on a mobile phone afterwards Each device on which a MIDlet
should be executed must provide an environment which guarantees execution and
administration of MIDlets This environment is called Application Management Software
(AMS) and controls the life cycle of the MIDlets A MIDlet can be like the well-known Java
Applet also only in one of three states Between the two states Paused and Active the MIDlet
can change during its runtime The state Destroyed is however final The MIDlet can even
change its states by the help of special methods, but must notify the AMS about it The AMS
can change the states of the MIDlets at any time This can happen if the resources of the
MIDlets are needed by other processes, for example in case of a incoming telephone call the
AMS sets the MIDlet into state Paused and the necessary display is used for the telephone
call
The MIDlet object is generated by the AMS and is first in the state Paused see Fig 11, thus
still no resources are blocked Afterwards the MIDlet is started by the AMS through a call of
the method startApp() Now the MIDlet is in state Active and all needed resources will
be requested From the state Active the MIDlet can change again into the state Paused
through the AMS or by itself If for example a telephone call arrives the AMS sets the MIDlet
into state Paused, since it needs some resources like for example the display of the MIDlet
The MIDlet asks periodically with the method resumeRequest() if it is allowed to run
again, in this case the AMS starts the MIDlet by means of the method startApp()
Fig 11 State diagram of a MIDlet
From the state Active the MIDlet can be set by itself or by the AMS into state Destroyed It
releases then all requested resources and stores if necessary application data for the further
use Afterwards the MIDlet can be eliminated by the Garbage Collector
4.5 Application Deployment
The occasionally complex installation was a big obstacle in the past which prevented a wide spreading of mobile applications Usually for this a PC with for the mobile phone suitable configuration software was necessary, with which the mobile phone was connected by a data cable For mobile Java applications there is another further alternative, which is favored
in particular by the mobile games market Here the installation of new MIDlets is at any time at each place within shortest time possible, always when the user needs certain programs for its mobile phone This is reached by the download of the desired MIDlet over
a UMTS or a GPRS connection The necessary URL for this receives the user either from the browser of the mobile phone or by SMS In addition such a call is also directly possible from
a MIDlet The development of specialized Part-MIDlets, for example for different equipment variants of a vehicle, is now possible which are downloaded on demand directly to the user's mobile phone
The protocol for such a Over The Air (OTA) transmission is HTTP Communication over HTTP is a firm component of MIDP and thus the standard technique for the data communication of MIDlets The support of further protocols is however optional In addition MIDlets offer with the method platformRequest(string URL) a standard procedure for the download of new programs over a HTTP connection
Apart from the MIDP specification the optional content Handler API (JSR 211) contains also this functionality Duty of the content Handler API is actually to pass certain tasks to other programs For example playing music at the on the mobile phone installed media player However it can be also used to download and to install new programs on the device With this kind of installation the appropriate jad and jar file must be on a web server reachable for the mobile device In the jad file thereby to the location of the jar file is referred
4.6 Security
In MIDP there is an extensive security concept, which on the public key procedure for the verification and authentication of MIDlet Suites is based This security concept serves the preventing of, the use of sensitive operations, like for example the establishment of a expensive network connection, without preventing the knowledge of the user So that a signed MIDlet can get access to a sensitive API, the appropriate permission must be set This permission is indicated in the jad file
In MIDP there are so-called Protection Domains which MIDlets are assigned to In the Protection Domains is specified how to deal with the permissions
There are the following Protection Domains:
minimum: MIDlets of these Protection Domain, access to all Permissions is refused
untrusted: The user must give his agreement with each call to an API proteceted by a Permission of these Protection Domain This is the default domain for unsigned MIDlets
trusted/maximum: The access to all Permissions of this Protection Domain is permitted
Trang 8One frequently still differentiates with trusted Protection Domains according to the
certification authority:
manufacturer: Uses certificates of the device manufacturer
operator: Uses certificates of the network provider
trusted third party: Uses third party certificates
With the permissions two types are differentiated:
allowed: The access is permitted without demand of the user
user: The user must give his agreement for the call of the associated API
With user Permissions between the following types one differentiates:
oneshot: Inquire with each call
session: Once inquire, decision remains valid as long as MIDlets of these MIDlet Suite are
active
blanket: Once inquired, decision remains valid as long as the MIDlet Suite is installed
If a MIDlet is in the trusted Protection Domain and the type of Permission is allowed, then it
can use the associated API without demand of the user
To which Protection Domain a MIDlet Suite belongs depends on the root certificate existing
on the devices With the installation the signature of the MIDlets is compared with the
existing root certificates and accordingly a classification is made
5 Vehicle integration
Cars are usually products, which come from one hand, from the car manufacturer The
offerers of accessory components so-called off board devices have a not insignificant
problem, since usually no standard interfaces for the integration of these devices are present
or must be licensed by the vehicle manufacturer But even if such a license and the necessary
installation interfaces are present, still the problem of the user interface remains for the
offerer of accessory components These are frequently goods in short supply and reserved
for the OEM (Original Equipment Manufacturer) in the vehicle From there the accessory
offerers mostly offer their own control elements, which are expenditure-stuck or stuck on
the instrument panel Apart from the optical lack that control elements does not fit the
design and cables lay partly openly, remains the problem, that these control elements do not
fit into the control concept of the vehicle
There is however one off board device, which is accepted by practically all car
manufacturers and for both, interfaces for the integration in the vehicle and a firm place in
the instrument panel is present In addition it is suitable outstanding as universal control
element for a multiplicity of devices Meant here is the mobile phone
Mobile phones are suitable on the one hand so well, because they possess many communication interfaces, beside the mandatory GSM, GPRS, UMTS support they frequently have Bluetooth and some models even WLAN interfaces The employment of wireless technologies makes besides the cable to the control elements redundantly The suitable communication technology can be selected depending upon application For vehicle-internal communication a short range technology is sufficient as for example Bluetooth However even if a genuine remote maintenance is to be realized over far distances a UMTS or a GPRS connection offers itself for this
On the other hand mobile phones can be programmed almost at will, so that control applications for the most diverse devices can be realized The advantages of the Java Micro edition in this area were stated already in detail
5.1 Example auxiliary heating
How the integration into a vehicle is in detail realized is to be described in the following by the example of a auxiliary heating The auxiliary heating is installed in the vehicle and attached to the CAN (Controller Area Network) bus of the car, over which all controllers are interlaced and receive their instructions The instructions come of one at the instrument panel fastened or into it inserted, control element which is likewise connected with the CAN bus Instead of this control element or also as addition of it now a mobile phone is to be used
In principle for this UMTS/GPRS and Bluetooth present themselves as communication technology Bluetooth for communication within the car and UMTS/GPRS for the remote maintenance from the domestic living room Since the integration is very similar in both cases and Bluetooth besides brings the standardized communication profiles with it, contains the following example for the sake of simplicity only to Bluetooth Following Fig
12 outlines the fundamental structure of such a system
Trang 9One frequently still differentiates with trusted Protection Domains according to the
certification authority:
manufacturer: Uses certificates of the device manufacturer
operator: Uses certificates of the network provider
trusted third party: Uses third party certificates
With the permissions two types are differentiated:
allowed: The access is permitted without demand of the user
user: The user must give his agreement for the call of the associated API
With user Permissions between the following types one differentiates:
oneshot: Inquire with each call
session: Once inquire, decision remains valid as long as MIDlets of these MIDlet Suite are
active
blanket: Once inquired, decision remains valid as long as the MIDlet Suite is installed
If a MIDlet is in the trusted Protection Domain and the type of Permission is allowed, then it
can use the associated API without demand of the user
To which Protection Domain a MIDlet Suite belongs depends on the root certificate existing
on the devices With the installation the signature of the MIDlets is compared with the
existing root certificates and accordingly a classification is made
5 Vehicle integration
Cars are usually products, which come from one hand, from the car manufacturer The
offerers of accessory components so-called off board devices have a not insignificant
problem, since usually no standard interfaces for the integration of these devices are present
or must be licensed by the vehicle manufacturer But even if such a license and the necessary
installation interfaces are present, still the problem of the user interface remains for the
offerer of accessory components These are frequently goods in short supply and reserved
for the OEM (Original Equipment Manufacturer) in the vehicle From there the accessory
offerers mostly offer their own control elements, which are expenditure-stuck or stuck on
the instrument panel Apart from the optical lack that control elements does not fit the
design and cables lay partly openly, remains the problem, that these control elements do not
fit into the control concept of the vehicle
There is however one off board device, which is accepted by practically all car
manufacturers and for both, interfaces for the integration in the vehicle and a firm place in
the instrument panel is present In addition it is suitable outstanding as universal control
element for a multiplicity of devices Meant here is the mobile phone
Mobile phones are suitable on the one hand so well, because they possess many communication interfaces, beside the mandatory GSM, GPRS, UMTS support they frequently have Bluetooth and some models even WLAN interfaces The employment of wireless technologies makes besides the cable to the control elements redundantly The suitable communication technology can be selected depending upon application For vehicle-internal communication a short range technology is sufficient as for example Bluetooth However even if a genuine remote maintenance is to be realized over far distances a UMTS or a GPRS connection offers itself for this
On the other hand mobile phones can be programmed almost at will, so that control applications for the most diverse devices can be realized The advantages of the Java Micro edition in this area were stated already in detail
5.1 Example auxiliary heating
How the integration into a vehicle is in detail realized is to be described in the following by the example of a auxiliary heating The auxiliary heating is installed in the vehicle and attached to the CAN (Controller Area Network) bus of the car, over which all controllers are interlaced and receive their instructions The instructions come of one at the instrument panel fastened or into it inserted, control element which is likewise connected with the CAN bus Instead of this control element or also as addition of it now a mobile phone is to be used
In principle for this UMTS/GPRS and Bluetooth present themselves as communication technology Bluetooth for communication within the car and UMTS/GPRS for the remote maintenance from the domestic living room Since the integration is very similar in both cases and Bluetooth besides brings the standardized communication profiles with it, contains the following example for the sake of simplicity only to Bluetooth Following Fig
12 outlines the fundamental structure of such a system
Trang 10Fig 12 Vehicle integration
The auxiliary heating and its control elements communicate no longer directly over CAN
bus with each another, but over an interface or a gateway The gateway controls the data
transfer in the vehicle and passes the data on to the respective control devices In the
concrete example the gateway has a Bluetooth SPP connection to the mobile phone, over
that it transfers the instructions of the remote control unit
On the mobile phone a Java MIDlet runs, which the user downloaded ideally-proved
directly from the Web server of the auxiliary heating manufacturer and installed it
afterwards on his device Security is ensured thereby by an appropriate signature of the
MIDlets, which regalements the access to resources of the mobile phone e.g communication
interfaces and memory
Even the selection of a suitable MIDlet for the
vehicle-auxiliary-heating-mobile-phone-combination can be automated to a large extent, if device type and Bluetooth address of the
user are deposited on a central server This is can be done by a service technician for
example with the installation
The scenario to the deployment of the application has the following in Fig 13 described
expiration
Fig 13 Automatic Application Deployment After the auxiliary heating was installed in the vehicle and the service technician has deposited the Bluetooth address, the telephone number and the type of device on the server starts the scenario
1 The vehicle starts a search for Bluetooth devices in the environment It acts around a functionality of the Bluetooth standard
2 The found devices convey their Bluetooth address for later identification
3 A list of the found devices is sent over a GPRS/UMTS connection to the server
4 The server examined on the basis the Bluetooth addresses whether it for one of the found devices an order has, and selects on the basis the deposited type information a MIDlet fitting to the device type
5 The server sends a SMS with the appropriate download link to mobile phone Subsequently, the user opens the link and downloads the MIDlet to his mobile phone
6 Subsequently, automatically the installation procedure begins The user now only has to agree with the installation
Trang 11Fig 12 Vehicle integration
The auxiliary heating and its control elements communicate no longer directly over CAN
bus with each another, but over an interface or a gateway The gateway controls the data
transfer in the vehicle and passes the data on to the respective control devices In the
concrete example the gateway has a Bluetooth SPP connection to the mobile phone, over
that it transfers the instructions of the remote control unit
On the mobile phone a Java MIDlet runs, which the user downloaded ideally-proved
directly from the Web server of the auxiliary heating manufacturer and installed it
afterwards on his device Security is ensured thereby by an appropriate signature of the
MIDlets, which regalements the access to resources of the mobile phone e.g communication
interfaces and memory
Even the selection of a suitable MIDlet for the
vehicle-auxiliary-heating-mobile-phone-combination can be automated to a large extent, if device type and Bluetooth address of the
user are deposited on a central server This is can be done by a service technician for
example with the installation
The scenario to the deployment of the application has the following in Fig 13 described
expiration
Fig 13 Automatic Application Deployment After the auxiliary heating was installed in the vehicle and the service technician has deposited the Bluetooth address, the telephone number and the type of device on the server starts the scenario
1 The vehicle starts a search for Bluetooth devices in the environment It acts around a functionality of the Bluetooth standard
2 The found devices convey their Bluetooth address for later identification
3 A list of the found devices is sent over a GPRS/UMTS connection to the server
4 The server examined on the basis the Bluetooth addresses whether it for one of the found devices an order has, and selects on the basis the deposited type information a MIDlet fitting to the device type
5 The server sends a SMS with the appropriate download link to mobile phone Subsequently, the user opens the link and downloads the MIDlet to his mobile phone
6 Subsequently, automatically the installation procedure begins The user now only has to agree with the installation
Trang 127 After finishing the installation the MIDlet is started directly and can be connected by Bluetooth with the auxiliary heating, in dependence of its signature The application is ready for use thereby and the user can control his auxiliary heating
6 Conclusion
The chapter showed that wireless communication already belongs in many areas of the automotive environment to the state of the art Straight development possibilities further with the integration of mobile phones are present nevertheless Bluetooth presents itself here
as almost ideal communication technology for many applications
For the development of mobile phone applications the Java Micro Edition is first choice, it offers not only large platform independence, but also detailed concepts to the deployment of applications or for security In addition APIs are available for all usual communication technologies
The mobile phone is the only off board device accepted by car manufacturers That makes it interesting for the manufacturers of accessory components to use these as control elements
A concept for this was explained in the chapter
7 References
Bluetooth SIG (2009) www.bluetooth.org
Breymann, U & Mosemann H (2008) Java ME Anwendungsentwicklung für Handys, PDA und
Co (Germann), Hanser, 3446229973, Munich
Trang 13Passive Wireless Devices Using Extremely Low to High Frequency Load Modulation
Hubert Zangl, Michael J Moser, Thomas Bretterklieber and Anton Fuchs
0
Passive Wireless Devices Using Extremely
Low to High Frequency Load Modulation
Hubert Zangl, Michael J Moser, Thomas Bretterklieber, and Anton Fuchs
Institute of Electrical Measurement and Measurement Signal Processing,
Graz University of Technology, Kronesgasse 5, A-8010 Graz
Austria
1 Introduction
Whereas passive wireless communication in the Ultra High Frequency (UHF) domain features
long ranges of several meters in free space, systems utilizing lower frequencies in the ELF
(Extremely Low Frequency) to HF (High Frequency) domain can be advantageous in
environ-ments with conductive materials or where large antennas are not prohibitive Additionally,
the operation range is well defined and can be practically restricted to several centimeters like
in Near Field Communication (NFC) Standard ECMA-340 Near Field Communication Interface
and Protocol (NFCIP-2) (2003), although this does not necessarily mean that communication is
secure Hancke (2008)
In this chapter we investigate passive wireless devices in the frequency range from almost
DC to tens of Megahertz, i.e from the ELF to the HF domain Common abbreviations for
the ITU frequency ranges are summarized in Table 1 The most common Radio Frequency
Identification (RFID) systems use the LF (@125 kHz) and the HF (@13.56 MHz) bands This
chapter also considers lower frequencies
Abbreviation Range Name subHz < 3 Hz SubHertz ELF 3 Hz - 30 Hz Extremely Low Frequency SLF 20 Hz - 300 Hz Super Low Frequency ULF 0.3 kHz-3 kHz Ultra Low Frequency VLF 3 kHz - 30 kHz Very Low Frequency
LF 30 kHz - 300 kHz Low Frequency
MF 300 kHz - 3 MHz Medium Frequency
HF 3 MHz - 30 MHz High Frequency VHF 30 MHz - 300 MHz Very High Frequency UHF 300 MHz - 3 GHz Ultra High Frequency
Table 1 ITU frequency ranges and abbreviations
We provide a brief introduction to the technology, performance estimations in terms of
pow-ering range with respect to permitted signal levels and human exposure issues, performance
considerations in terms of data transmission range with respect to background and man-made
noise, and analysis of the impact of conductive/dielectric materials in the vicinity of the
pas-sive wireless devices (transponders)
6
Trang 14We provide an introduction to the concept of load modulation techniques for passive wireless
communication Usually, RFID systems in the low to high frequency range (LF to HF) are
considered as loosely inductively coupled transformers
The basic principle of such mainly inductively coupled systems is shown in Figure 1 A
pri-mary coil of the reader generates an alternating magnetic field and induces a voltage in the
coil antenna of the wireless device The primary coil is connected to a diplexer that carries
out frequency separation between the power supply path and the data path The
alternat-ing magnetic field may penetrate layers of air, liquids (e.g water) or layers of stainless steel
and other weak conductors and will then induce a voltage in the coil antenna of the wireless
device A tuning element (e.g a capacitor) and a power harvesting and storage unit (mainly
comprising a rectifier and a storage capacitor) are needed to power the electronic components
A demodulator can extract data sent from the ”reader” The transponder itself can transmit
data by means of load modulation This is, e.g., performed by a logic-controlled switch that
changes the load of the secondary coil The control logic can read out a sensor (e.g a change
in resistance or capacitance of a temperature or pressure sensor) and transmit this data back
to the reader
Air and/or metal
Power Harvesting
Load Modulation
Fig 1 Principle of passive wireless reader-transponder pair in the ELF to HF bands
2 Application Examples
Various fields of application can be thought of for passive wireless devices in or behind metal
housings powered by low frequent magnetic fields In this section, we present example
appli-cations
Transmitting measurement data through a double-walled stainless steel vessel can be
neces-sary when extreme temperatures, high pressures, or other harsh environmental conditions
(e.g hazardous substances) are present This could be a thermally insulated liquid hydrogen
storage tank in a car, a whipped cream maker or a chemical reactor Figure 2(a) shows a
sim-plified block diagram of a setup Figure 2(b) shows an example experimental setup using a
whipped cream maker The corresponding transponder is immersed in the liquid inside the
vessel
Another interesting application is e.g for magnetic stirrers, which are standard devices in
chemical laboratories Equipping the magnetic stirring bar (a bar magnet with a protective
coating made from either PTFE or stainless steel) with a miniaturized RFID tag that supplies
a sensor interface, one could sense and display process parameters directly from the fluid
that is stirred and thereby merge multiple devices (e.g magnetic stirrer, temperature sensor,
pH sensor) to a single device, which may need less space and reduce total equipment costs
Reader Transponder in double-walled stainless steel housing
Air and/or liquid
Power Harvesting
Load Modulation
Fig 2 (a) Schematic of a measurement setup for transmitting measurement data (e.g sure or temperature) through a double-walled stainless steel vessel (b) Photo of an examplemeasurement setup for transmitting temperature data (also other quantities such as pressurecould be measured) through a thermally insulated double-walled stainless steel vessel Here,the passive transponder is placed in a whipped cream maker and could be used, e.g., to mon-itor the temperature of the liquid
pres-Figure 3(a) depicts the schematic of such a setup, pres-Figure 3(b) shows an example laboratorysetup
Figure 3(a) depicts the schematic of such a setup, Figure 3(b) shows an example laboratorysetup
3 Comparison of Frequency Ranges from ELF to LF
The power that can be transmitted to wireless electronic devices by means of inductive pling is rather limited by restrictions of the field strength than by technological limits E.g.,power transmissions of up to 60 W have been reported in Kurs et al (2007) However, inpractice we are faced with limitations of the permitted field strength, due to both electromag-netic compatibility and human exposure issues The investigations in this section are based
cou-on the limits provided in ERC Recommendaticou-on 70-03: Relating to the use of short range devices
(SRD) (2007) for limits regarding electromagnetic compatibility and ICNIRP (1998) regarding
reference levels with respect to human exposure to alternating magnetic fields for the generalpublic
Electronic circuitry usually requires DC operating voltage Therefore, passive devices require
a rectifier circuit and an energy storage Both diodes and transistors can be used for the fier, where transistors often offer the advantage of lower voltage drops For the operation ofthe circuit it is important to achieve a certain minimum voltage Consequently, the slew rate
recti-of the magnetic field must be high enough This can be achieved by a high frequency and/or
a high field magnitude
Figure 4 shows Root Mean Square (RMS) reference levels for head, neck and trunk for thegeneral public according to ICNIRP (1998) In the frequency range of up to 100 kHz, the peakvalues can be√2 higher than the RMS values In the range from 100 kHz to 10 MHz, thepermitted peak values increase to 32 times the RMS limit
Trang 15We provide an introduction to the concept of load modulation techniques for passive wireless
communication Usually, RFID systems in the low to high frequency range (LF to HF) are
considered as loosely inductively coupled transformers
The basic principle of such mainly inductively coupled systems is shown in Figure 1 A
pri-mary coil of the reader generates an alternating magnetic field and induces a voltage in the
coil antenna of the wireless device The primary coil is connected to a diplexer that carries
out frequency separation between the power supply path and the data path The
alternat-ing magnetic field may penetrate layers of air, liquids (e.g water) or layers of stainless steel
and other weak conductors and will then induce a voltage in the coil antenna of the wireless
device A tuning element (e.g a capacitor) and a power harvesting and storage unit (mainly
comprising a rectifier and a storage capacitor) are needed to power the electronic components
A demodulator can extract data sent from the ”reader” The transponder itself can transmit
data by means of load modulation This is, e.g., performed by a logic-controlled switch that
changes the load of the secondary coil The control logic can read out a sensor (e.g a change
in resistance or capacitance of a temperature or pressure sensor) and transmit this data back
to the reader
Air and/or metal
Power Harvesting
Load Modulation
Fig 1 Principle of passive wireless reader-transponder pair in the ELF to HF bands
2 Application Examples
Various fields of application can be thought of for passive wireless devices in or behind metal
housings powered by low frequent magnetic fields In this section, we present example
appli-cations
Transmitting measurement data through a double-walled stainless steel vessel can be
neces-sary when extreme temperatures, high pressures, or other harsh environmental conditions
(e.g hazardous substances) are present This could be a thermally insulated liquid hydrogen
storage tank in a car, a whipped cream maker or a chemical reactor Figure 2(a) shows a
sim-plified block diagram of a setup Figure 2(b) shows an example experimental setup using a
whipped cream maker The corresponding transponder is immersed in the liquid inside the
vessel
Another interesting application is e.g for magnetic stirrers, which are standard devices in
chemical laboratories Equipping the magnetic stirring bar (a bar magnet with a protective
coating made from either PTFE or stainless steel) with a miniaturized RFID tag that supplies
a sensor interface, one could sense and display process parameters directly from the fluid
that is stirred and thereby merge multiple devices (e.g magnetic stirrer, temperature sensor,
pH sensor) to a single device, which may need less space and reduce total equipment costs
Reader Transponder in double-walled stainless steel housing
Air and/or liquid
Power Harvesting
Load Modulation
Fig 2 (a) Schematic of a measurement setup for transmitting measurement data (e.g sure or temperature) through a double-walled stainless steel vessel (b) Photo of an examplemeasurement setup for transmitting temperature data (also other quantities such as pressurecould be measured) through a thermally insulated double-walled stainless steel vessel Here,the passive transponder is placed in a whipped cream maker and could be used, e.g., to mon-itor the temperature of the liquid
pres-Figure 3(a) depicts the schematic of such a setup, pres-Figure 3(b) shows an example laboratorysetup
Figure 3(a) depicts the schematic of such a setup, Figure 3(b) shows an example laboratorysetup
3 Comparison of Frequency Ranges from ELF to LF
The power that can be transmitted to wireless electronic devices by means of inductive pling is rather limited by restrictions of the field strength than by technological limits E.g.,power transmissions of up to 60 W have been reported in Kurs et al (2007) However, inpractice we are faced with limitations of the permitted field strength, due to both electromag-netic compatibility and human exposure issues The investigations in this section are based
cou-on the limits provided in ERC Recommendaticou-on 70-03: Relating to the use of short range devices
(SRD) (2007) for limits regarding electromagnetic compatibility and ICNIRP (1998) regarding
reference levels with respect to human exposure to alternating magnetic fields for the generalpublic
Electronic circuitry usually requires DC operating voltage Therefore, passive devices require
a rectifier circuit and an energy storage Both diodes and transistors can be used for the fier, where transistors often offer the advantage of lower voltage drops For the operation ofthe circuit it is important to achieve a certain minimum voltage Consequently, the slew rate
recti-of the magnetic field must be high enough This can be achieved by a high frequency and/or
a high field magnitude
Figure 4 shows Root Mean Square (RMS) reference levels for head, neck and trunk for thegeneral public according to ICNIRP (1998) In the frequency range of up to 100 kHz, the peakvalues can be√2 higher than the RMS values In the range from 100 kHz to 10 MHz, thepermitted peak values increase to 32 times the RMS limit