WO2002015075A1 - Procédé et appareil permettant de fournir un serveur wap mobile - Google Patents

Procédé et appareil permettant de fournir un serveur wap mobile Download PDF

Info

Publication number
WO2002015075A1
WO2002015075A1 PCT/SE2001/001742 SE0101742W WO0215075A1 WO 2002015075 A1 WO2002015075 A1 WO 2002015075A1 SE 0101742 W SE0101742 W SE 0101742W WO 0215075 A1 WO0215075 A1 WO 0215075A1
Authority
WO
WIPO (PCT)
Prior art keywords
bluetooth
wap
mobile
applications
server
Prior art date
Application number
PCT/SE2001/001742
Other languages
English (en)
Other versions
WO2002015075B1 (fr
Inventor
Gilbert Bengtsson
Roberto Busso
Georg De Laval
Anders Holmberg
Kjell Svensson
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to AU2001280391A priority Critical patent/AU2001280391A1/en
Publication of WO2002015075A1 publication Critical patent/WO2002015075A1/fr
Publication of WO2002015075B1 publication Critical patent/WO2002015075B1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information

Definitions

  • the present invention relates to wireless radiocommunication systems.
  • the present invention relates to a method and apparatus for providing location dependent information services.
  • Some location based services now exist such as, for example, that described in U.S. Patent No. 6,091,956 to Hollenberg.
  • a system is described for providing services and time-critical information about places and events to mobile users proximate to their current location.
  • auxiliary computer terminal which is provided on the theory that by using, for example, a cellular telephone for the provision of location based services, costs would be prohibitive.
  • costly GPS services are provided in the auxiliary terminal to provide the locating function. Problems arise in this system in that, for example, several locating functions must be provided to correlate mobile users and their locations to merchants and their locations through notoriously unreliable and band-limited satellite links.
  • Another system described in U.S. Patent No. 6,058,098 to Moon, et al, includes automatically configuring software in a portable intelligent communication device where the software settings are dependent on location information.
  • location information may be provided, for example, by GPS and may be correlated to within a cell size. It is not disclosed that location based information such as that provided by merchants or other location based services are provided. It is further not disclosed whether applications are necessarily designed specifically for a portable intelligent communications device by the manufacturer of the device or whether it is possible to provide such location information to any software application.
  • WAP Wireless Applications Protocols
  • WAP applications may include Internet information retrieval, where WAP may be used to allow wireless subscribers to access the Internet. It should be noted that certain mobile terminals may limit the ability of a user to access the Internet. Limitations such as memory size and the like may significantly reduce the ability of a user to navigate the Internet using a mobile wireless terminal.
  • WAP Wireless Fidelity
  • email notification including interactive requests for additional information
  • access to payment services telephone call setup service menus and the like.
  • the opportunity to provide WAP services unfortunately has traditionally been limited to only those with the knowledge and the contacts within industries closely linked to the wireless community and, as a result, application development has been sparse.
  • smaller potential beneficiaries of WAP e.g. small merchants and the like, and small proprietary users are effectively cut out of the WAP market.
  • the undesirable consequence associated with the limited number of appealing WAP applications has been to limit the appeal of wireless devices in general.
  • one or more Mobile WAP-Bluetooth server units may be provided to customers, including one or more qualified third party developers.
  • a WAP-Bluetooth Software Developer Kit SDK
  • SDK WAP-Bluetooth Software Developer Kit
  • developers as well as the applications they provide may be subject to qualification by way of, for example, a certification process.
  • one or more qualified WAP- Bluetooth applications developed by the third party developers may be provided to the customers such that the qualified applications may be loaded on the Mobile WAP-Bluetooth server units for actually providing location dependent information services to one or more customers and one or more mobile WAP-Bluetooth terminals.
  • One or more WAP-Bluetooth client terminals may be connected with, for example by one or more Mobile WAP-Bluetooth servers, and one or more location-dependent WAP pages pushed toward the WAP-Bluetooth client terminals using a WAP-Bluetooth application executing on the Mobile WAP-Bluetooth servers.
  • a WAP-Bluetooth signal may be transmitted, for example, by one or more Mobile WAP-Bluetooth servers in a coverage area associated with the location dependent information service and connections made with one or more WAP-Bluetooth client terminals to provide the location dependent information service.
  • One or more qualified WAP-Bluetooth applications may be registered such that the qualified WAP-Bluetooth applications are available to the customers and the third party developers in, for example, a product registry such as a database or the like. Accordingly, the qualified WAP-Bluetooth applications may be presented and provided on a trial basis to the customers using for example, a website.
  • the SDK may include, for example, a WAP-Bluetooth development environment, WAP-Bluetooth software modules, and documentation.
  • the SDK may further include a bootloader, a software platform, and a basic WAP-Bluetooth application which WAP-Bluetooth application may serve as an examples although other examples ranging from simple to complex may be provided in the SDK.
  • the software platform provided with the SDK may further include, for example, a Bluetooth stack, an operating system, and drivers corresponding to one or more hardware interfaces which are to be supported. It should be noted that he SDK may includes one or more open source software components.
  • the WAP-Bluetooth development environment may includes a graphical user interface development tool which may be associated with Microsoft ® Windows ® operating environment, UNIX operating environment, or the like.
  • FIG 1A is a diagram illustrating an exemplary Bluetooth service environment in accordance with exemplary embodiments of the present invention
  • FIG IB is a diagram illustrating an exemplary Bluetooth service environment using an exemplary mobile WAP-Bluetooth server in accordance with exemplary embodiments of the present invention
  • FIG 2 is an entity relationship diagram illustrating exemplary components of an exemplary mobile WAP-Bluetooth server environment in accordance with exemplary embodiments of the present invention
  • FIG 3 is a block diagram illustrating exemplary blocks of an exemplary mobile WAP-Bluetooth server in accordance with exemplary embodiments of the present invention
  • FIG 4 is a block diagram further illustrating exemplary blocks of an exemplary mobile WAP-Bluetooth server in accordance with exemplary embodiments of the present invention
  • FIG 5A is a diagram illustrating exemplary layers of an exemplary mobile WAP-Bluetooth application development environment in accordance with exemplary embodiments of the present invention
  • FIG 5B is a diagram illustrating an exemplary memory map for use in an exemplary mobile WAP-Bluetooth application development environment in accordance with exemplary embodiments of the present invention
  • FIG 6 is a diagram illustrating an exemplary mobile WAP-Bluetooth user scenario in accordance with exemplary embodiments of the present invention.
  • FIG 7 is a diagram illustrating an exemplary mobile WAP-Bluetooth user scenario in accordance with alternative exemplary embodiments of the present mvention.
  • a location-oriented service may be provided wherein local information is communicated in accordance with the Bluetooth standard to a mobile WAP- Bluetooth device, such as, for example, a mobile phone, PDA, and the like, or any device which has a Bluetooth interface and an appropriate application developed, for example, in accordance with the present invention, for providing services from a mobile WAP-Bluetooth server further in accordance with the present invention.
  • a mobile WAP- Bluetooth device such as, for example, a mobile phone, PDA, and the like, or any device which has a Bluetooth interface and an appropriate application developed, for example, in accordance with the present invention, for providing services from a mobile WAP-Bluetooth server further in accordance with the present invention.
  • Location based information services provided accordingly due to characteristics associated with, for example, the localized nature of providing such services, possesses many advantages including acting as an information overflow filter to reduce the amount of information a user must process to that which is presumed to be of interest based on, for example, intimate geographic proximity.
  • FIG 1A where exemplary mobile WAP-Bluetooth environment 100 is shown
  • a connection may be established between mobile WAP-Bluetooth terminal 130 and, for example Internet 110 where Customer Location-oriented information 120 may be transferred to user 140 through message 122 sent to mobile WAP-Bluetooth terminal 130.
  • Customer Location-oriented information 120 may be transferred to user 140 through message 122 sent to mobile WAP-Bluetooth terminal 130.
  • information which is highly localized may be transferred to user 140 in a location specific manner not possible with prior art solutions. Since the potential applications of such a proximity oriented or location dependent service are literally boundless and will be described in greater detail hereinafter, it will be sufficient for now to understand basic Bluetooth service in accordance with various embodiments of the present invention.
  • Bluetooth service environment 100 may be further understood by considering mobile WAP-Bluetooth server 140 which may be connected, for example, to a standard computer 150 for providing an adjunct, a high speed connection to the Internet, an auxiliary server to an adjunct website or may preferably operate in a stand alone manner so that mobility may be maintained.
  • standard computer 150 may be preferably be used for downloading applications to mobile WAP-Bluetooth server 140 through a serial interface using, for example, a cable.
  • software for maintenance of mobile WAP-Bluetooth server 140 may be developed so that it runs on, for example, standard computer 150.
  • mobile WAP-Bluetooth terminals 130 may be provided with push services that, for example, a third party application development customer may want to mediate. It should be noted that information that such a third party customer may prefer to mediate in such a manner may be isolated from other information services due largely to the limited range accorded to Bluetooth server 140. While ranges of 100 meters are possible, a typical range of from 10m to 30m ensures that a certain amount of inherent isolation is possible using Bluetooth based service provision in accordance with the present invention and in accordance with the Bluetooth standard as outlined in the Bluetooth Specification v 1.0A. In particular, the Interoperability Requirements for Bluetooth as a WAP Bearer at pages 495 to 513 of the Bluetooth specification, id.
  • server 140 may push, for example, web pages onto user 140's mobile WAP-Bluetooth terminal 130 that application development and/or service provision customers, e.g. customers which have purchased one or more mobile WAP-Bluetooth servers 140, want to mediate.
  • mobile WAP-Bluetooth server 140 may preferably, in accordance with various embodiments of the present invention, provide pushed information for free.
  • mobile WAP-Bluetooth server 140 provides a service that uses both WAP and Bluetooth to mediate location-specific information to a mobile WAP- Bluetooth terminal 130 which while illustrated as, for example, a cellular phone, may also take the form of a PDA or like device for providing, for example, mobile Internet or additional integrated services.
  • power supply 221 represents the hardware needed to generate a minimum regulated voltage of 3.3V that all circuits may use. Power supply 221 may further operate with input voltages of between 4.5 and 12V and will preferably not be damaged if input polarity is reversed or if input voltage rises as high as 30V.
  • Reset circuitry 222 may be provided and may be responsible for forcing hardware into a known and well-defined startup state when power supply voltage rises to over 3. IV.
  • An active low reset signal for example, may be distributed to any hardware within the mobile WAP-Bluetooth server such as, for example, a CPU, a Bluetooth transceiver module (hereinafter referred to as "Bluetooth interface”), and FLASH memory.
  • Init 223 may be software executed by bootloader 233 immediately after start-up from reset. Init 223 may perform basic setup of, for example, mobile WAP-Bluetooth server hardware environment 220, e.g. setting up connections to memories and the like. It should be noted that since bootloader 233 itself may reside in an external FLASH memory, the FLASH memory must be connected so that it can be reached during start-up before init 223 software has set up any chip- selects. As part of init 223 process, status LED 211 may be turned on in order to indicate to a user that valid power is present in the system. Further as part of init 223, basic hardware tests may be performed in power-on self test 226. Any errors found may be communicated as error indication 227. The unit may attempt to continue with operation if only minor errors are found, but major errors will result in a halt attempt.
  • status LED 211 may be turned on in order to indicate to a user that valid power is present in the system.
  • basic hardware tests may be performed in power-on self test
  • SW integrity test 225 may be performed including, for example, a memory integrity check of the mobile WAP-Bluetooth application software load. Accordingly, a checksum may be calculated over the stored application and compared with a separately stored checksum stored when the application was downloaded. If a checksum error is found, process execution will remain within bootloader 233, without launching the erroneous application. If errors are found during SW integrity check 225 a coarse indication of the cause of the error may be indicated to the user by flashing the LED in accordance with different error types. Error types may be indicated by use of a different number of flashes for each error and preferably only the most severe may be indicated if multiple errors have been found. It should be noted that such indication may not be applicable if the LED itself is the cause of the error.
  • RS232 port 228 may be provided for serial connection. Included in RS232 port 228 may be, for example, an advanced buffered UART which may be built- into the CPU, and an, for example, an external RS232 transceiver which handles the conversion between electrical RS232 levels and logical 3.3V signal levels. RS232 port 228 circuitry may also includes some filtering facilities in order to avoid/suppress EMC/ESD problems. It should be noted that RS232 port 228 hardware may preferably be designed to operate at up to 115.2 kbps. A set of serial drivers 230 may also be needed to communicate over the serial line.
  • the serial line should be set up for standard asynchronous communication, such as, for example, 8 data bits, no parity bits, I stop bit, 9600 bps.
  • bootloader 233 may communicate with, for example, maintenance application 234 using a simple bootloader protocol 235. If a valid mobile WAP-Bluetooth application is present in FLASH memory, and if no connection from a maintenance tool has been established, a mobile WAP- Bluetooth application may be launched after a well-defined time after start-up. The purpose of the time delay is that a malfunctioning application might fail to enter the bootloader upon request from a maintenance tool.
  • the CPU in an exemplary mobile WAP-Bluetooth server may further feature an advanced timer driver 231.
  • FLASH drivers 232 may be stored in bootloader 233 to be protected, so that a malfunctioning application cannot by accident erase itself.
  • the sector in which bootloader 233 is stored may be hardware protected so that no software will be able to erase it accidentally.
  • special software drivers are required.
  • a special characteristic of FLASH programming is that FLASH drivers 232 cannot be executed from the same memory chip that it attempts to write/erase in. Therefore, FLASH drivers 232 must be copied from the FLASH into the RAM before it is used.
  • bootloader 233 is a small standalone application responsible for basic HW initialization, basic system testing, and for launching the mobile WAP-Bluetooth application.
  • the administrator can update or replace the mobile WAP-Bluetooth application by downloading new data to the device using a serial Bootloader Protocol.
  • Bootloader 233 may be stored in a dedicated sector of FLASH memory, which may be possible to boot from during start-up. It should be noted that bootloader 233 may be programmed into mobile WAP-Bluetooth server as part of the manufacturing process. It should also be noted again that bootloader 233 may be protected so that it cannot be accidentally overwritten by the application's software.
  • eCos 295 may be used for low level operation. ECos 295 may preferably be an open-source, royalty-free, highly configurable, operating system ideal for embedded systems. In accordance with supporting a mobile WAP-Bluetooth application, eCos 295 operating system may provide support for different kinds of hardware, e.g. serial device drivers and may be considered to be a vital part of SDK 280, making it easier for third party developers to develop applications. In addition, eCos 295 makes it easier to port, for example, Bluetooth stack 290 to a mobile WAP-Bluetooth server because it implements components such as threads, mutexes and timers. Accordingly, eCos makes it easier to extend mobile WAP-Bluetooth server functionality, e.g. by adding a TCP/IP stack or the like.
  • Host Controller Interface (HCl) 294 is an additional part of Bluetooth stack 290.
  • HCl 294 may provide a uniform interface between the Host and Bluetooth Hardware, i.e. the Link Manager in the Bluetooth hardware.
  • HCl 294 also provides transparency, e.g. the same Host software may be used on different hardware, e.g. RS232 and USB.
  • Service Discovery Protocol (SDP) 291 is yet another part of Bluetooth stack 290. SDP 291 may provide the ability, for example, for terminal applications to discover the existence of services provided by server applications, mobile WAP-Bluetooth server is a typical server application providing service to terminals.
  • Logical Link Control and Adaptation Protocol (L2CAP) 293 is yet another part of Bluetooth stack 290.
  • L2CAP 293 provides the capability for: protocol multiplexing, e.g. enables usage of several higher layer protocols; segmentation and reassembly, e.g. may segment higher layer protocols packets; guaranteeing quality of service, e.g. negotiates QoS contracts.
  • RFCOMM 292 is still another part of Bluetooth stack 290. RFCOMM 292 simulates a simple serial cable replacement between two Bluetooth devices.
  • a mobile WAP-Bluetooth server in accordance with the present invention may use up to seven instances of RFCOMM 292 component to simulate serial communication with up to seven terminals.
  • WAP information may be stored together with the application, for example, as linked in the maintenance application or may be stored separately from the application. If WAP information is stored separately, a mobile WAP-Bluetooth server in accordance with exemplary embodiments of the present invention preferably requires a FLASH memory file system.
  • Such a component simulates a file system, e.g. using functions such as open file, write to file and close file, using a FLASH memory.
  • the Microsoft Windows version of SDK 280 may preferably be using CygWin development environment 275 preferably consisting of parts of the popular GNU development tools and utilities for Windows NT and 9x. CygWin development environment 275 may be available without charge and its components are covered by a number of different licenses, e.g. GPL and public domain. Accordingly, binutils 271 is a set of small basic tools to manipulate binary, e.g. object and library files for the target platform. In addition, GNU Compiler
  • Gcc 272 may include C and C+ + crosscompilers for the CPU in the mobile WAP-Bluetooth hardware, e.g. ARM7TDMI processor. Gcc 272 may also include a linker, capable of linking relocatable object modules into located ELF binaries. Gdb/insight 273 is preferably a text-mode cross-debugger, which may either be used for simulation of the target environment, or for remote debugging of the mobile WAP-Bluetooth hardware.
  • Remote debugging can be done either by using a low-cost serial RS232 connection in conjunction with a gdb stub 274 as will be described in greater detail herein below, or by connecting through a high- performance JTAG debugger directly to the hardware emulation facilities built-into the CPU core of the mobile WAP-Bluetooth hardware.
  • Insight is a convenient and powerful graphical user interface to the gdb. There are a number of graphical interfaces to gdb to choose from, but one advantage with the Insight user interface is that it is portable to both Windows and Unix platforms.
  • gdb/insight 273 preferably requires communication with a software monitor running in the target hardware called a stub, and may preferably be either a stand-alone application, or may be linked into the debugged application.
  • a stub a software monitor running in the target hardware
  • gdbstub 274 may be linked, for example, into bootloader 233, and may also be supplied as code in SDK 280 to link into the mobile WAP-Bluetooth application.
  • the CPU in a mobile WAP-Bluetooth server in accordance with the present invention may preferably be a 32-bit RISC architecture such as may be available, for example, from ARM Ltd. Such a CPU may have the ability to execute code in either an "ARM" 32-bit mode, or in a "Thumb” 16-bit mode. Since advantages and disadvantages exist with ranning in either mode, SDK 280 may preferably be designed to support both ARM and Thumb modes in the form of toolset 283. In accordance with documentation 282 provided with SDK 280, examples 281 may be provided containing well-structured and commented source code, and documentation e.g. README files.
  • examples 281 The purpose of examples 281 is to make it easy for the third party developer to get started developing applications for the mobile WAP-Bluetooth hardware. Simple examples 281 will include, for example, getting the LED to blink, while complex examples 281 include a mobile WAP- Bluetooth application itself. The amount of work necessary to understand examples 281 will be less than trying to understand the mobile WAP-Bluetooth application directly if made only from coarse specifications. It should be noted that the supplier of the mobile WAP-Bluetooth server hardware may preferably provide examples 281 written in a manner and to a standard most conducive to eventual certification of third party software as will be described in greater detail hereinafter.
  • SDK 280 may preferably contain a GNU development environment, SW components and Documentation 282 for example including installation and operation and may further include some examples and Application Notes.
  • GNU toolset 283 may be designed for use in multiple development platform environments including, for example, WinNT and Linux as main targets. It should be noted however that other Win32-and UNLX-platforms may also be expected to serve as suitable development platforms.
  • an application may be provided for servicing the mobile WAP-Bluetooth device, it includes functions for downloading binary WAP-pages onto the mobile WAP-Bluetooth device.
  • Signed applets 218 may be provided in which, for example, a Java script may be granted special privileges by a browser, such as the ability to read and write local files, not normally available to untrusted applets. Signed applets 218 may implement the functionality described in the sections below related to the WML Templates 219a and WAP/WML Compiler 219b
  • WML Templates 219a may be used for creating WAP- pages.
  • WAP/WML Compiler 219b may be a compiler for WAP-pages which converts pages written in WML to binary WAP-format which may then be loaded onto a mobile WAP-Bluetooth server device.
  • Outer casing 217 may be provided which protects the mobile WAP-Bluetooth server circuit board and gives an attractive impression of the device. It should further be noted that the outer casing may provide functional and non-functional features as may be further described in copending design application number D00828, supra. It should be noted that it may be further desirable to provide examples 281 including source code examples of how to make file transmission to PDAs and related mobile terminals as a standard part of SDK 280.
  • third party SW application developers may be involved in an early stage in the initial release of mobile WAP-Bluetooth server hardware in order to create a base 282 of quality applications that may be of interest to customers wanting to provide a particular service using the mobile WAP-Bluetooth server as a delivery platform.
  • Resources 283 may further be provided for third party developers, such as SW downloads of around 50K in size.
  • mobile WAP-Bluetooth server may create new business 284 for third party SW developers. Provisions of SDKs, interaction of third party developers with each other through the website and the like, may be provided according to a business method further described in copending application number 040042-003, supra.
  • Bluetooth data transfer may include transfer between a mobile WAP- Bluetooth server and one mobile terminal. This functionality will use the RFCOMM layer to simulate a simple serial cable replacement between two devices, mobile WAP-Bluetooth server must not be able to connect automatically to the mobile terminal and is preferably hard coded.
  • Multi session 212 Bluetooth data transfer may include transfer between mobile WAP-Bluetooth server and several terminals. Accordingly, mobile WAP-Bluetooth server must not be able to connect automatically to new terminals entering the area and, for example, connections with terminals can be hard coded. Each mobile terminal may be sent the same WAP contents upon request.
  • mobile WAP-Bluetooth server may automatically establish a connection with Bluetooth mobile terminals or other mobile WAP-Bluetooth servers entering the area of reception, as long as the total number of connected devices do not exceed the maximum number which can be services by one mobile WAP-Bluetooth server which is preferably seven. Mobile mobile WAP-Bluetooth terminals leaving the service area will automatically be disconnected. Upon connection, each new mobile mobile WAP-Bluetooth terminal may be sent the same WAP contents.
  • status LED 211 might signal contact with a mobile mobile WAP-Bluetooth terminal by blinking with a high frequency and further may signal that it is waiting for a mobile mobile WAP- Bluetooth terminal to get in to reach with a low frequency blink.
  • WAP push 215 may provide functionality for pushing WAP web pages onto other terminals.
  • mobile WAP-Bluetooth system 252 may be provided in accordance with the present invention and may include: mobile WAP-Bluetooth server hardware 220, web site 250, a mobile WAP-Bluetooth application 270, 210 for transferring binary WAP-pages to mobile WAP-Bluetooth devices, and SDK 280.
  • User manual 251 may further be provided for the mobile WAP-Bluetooth system 252, describing how to use, for example, mobile WAP-Bluetooth server hardware 220 with a default software application for, for example, sending web pages to mobile WAP-Bluetooth terminals. It should be noted that user manual 251 is preferably not intended as a detailed developer manual for the third party application developers.
  • a demand 253 for mobile WAP-Bluetooth equipped terminals may be generated and thus enabling the terminal owner to benefit 254 from the applications and further increasing the demand for mobile WAP-Bluetooth server hardware 220.
  • mobile WAP-Bluetooth will enable information push 255 from information supplier to terminal owners. By enabling information push 255, e.g. wireless distribution of services, mobile WAP-Bluetooth will be able to promote the owners business 257.
  • new applications carried by mobile WAP-Bluetooth provide services which, again benefit 254 to the user and the provider, mobile WAP-Bluetooth through appearance and performance, generates 256 a desire to own mobile WAP- Bluetooth related hardware. It should further be noted that possession of, for example, a mobile WAP-Bluetooth mobile terminal or a mobile WAP-Bluetooth server may have increased social value 258.
  • Third party developers therefore may be categorized generally into three main categories: business developers, private developers, and industry developers. Examples of different groups may include, for the business category: local information broadcasts such as, for example, from mobile WAP-Bluetooth servers placed within a tour bus or the like which may provide information related to the sight in the vicinity of the server.
  • a mobile WAP-Bluetooth post which could indicate to users proximate to a private developer's mobile WAP-Bluetooth post information associated with the private developer such as name, personal information to be shared and the like could be provided. It should be noted however that it may be desirable to protect such information using a password or other user identification in order not to provide strangers with overly sensitive information.
  • a business development application might include a mobile WAP-Bluetooth port development kit which makes development easier for a private user.
  • sophisticated private users might be able to use the basic mobile WAP-Bluetooth application and SDK to do development.
  • Other examples of private developer applications might include personal agents for filtering information provided by mobile WAP-Bluetooth servers. For example, if a user is a not interested in a certain sight among sights which will be visited by the tour bus, as further provided by a list delivered to the users, it may be desirable for a user terminal to automatically exclude information related to the specified sight.
  • industry category might include, for example, a robotics control application using one or more mobile WAP-Bluetooth servers.
  • Such industry applications could be developed as a joint effort or may be developed solely by the equipment provider or industrial developer customer.
  • tools used to develop all software within the mobile WAP-Bluetooth development environment are preferably open source.
  • Tools are preferably known and used by a large developer community, and preferably have a reputation of being products of high quality.
  • software platform components shipped within, for example, SDK 280 are preferably open source.
  • suitable open source components are available, for example, on the Internet, such components are preferably used in the mobile WAP-Bluetooth development environment rather than custom components, although custom development is possible.
  • open source software products developed today often experience considerable goodwill benefits, compared to products developed and marketed in more traditional ways. Related products therefore may be potentially easier to market and sell simply by providing the product with open source.
  • user groups may be more patient in awaiting the release of software with extended functionality and may be even more tolerant of bugs and errors within the system with the expectation that open source software allows bugs to be fixed more easily.
  • an open source product could be brought to market earlier in the development phase by bypassing a large amount of development and testing before being acceptable to the user community.
  • the mobile WAP-Bluetooth standard will be TG4 compatible.
  • the mobile WAP-Bluetooth server is preferably not configured for ad-hoc networking in general although ad-hoc configurations may be useful in some applications.
  • hardware associated with a mobile WAP-Bluetooth server in accordance with the present invention may be configured depending on the size of the mobile WAP-Bluetooth application to be developed.
  • the mobile WAP-Bluetooth hardware may be designed for later add-on extensions to memory size and the like.
  • no one general solution will support all potential clients. Therefore, it is preferable to support a few clients although it should be noted that application developers may be inclined and are in fact encouraged to support as many different clients as possible.
  • one-way communication is preferably supported by the mobile WAP-Bluetooth server, i.e. WAP-pages may be pushed onto a mobile mobile WAP-Bluetooth terminal or client; while the mobile WAP-Bluetooth client will not be able to, for example, search the Internet through the mobile WAP-Bluetooth server.
  • a mobile WAP-Bluetooth server in accordance with the present invention may include Bluetooth radio module 321 for providing a standard Bluetooth interface 320. Further included is a set of low- level Bluetooth protocol parts (the "baseband") available as a software library, which is described in greater detail hereinafter and may be executed preferably in specially designed ARM7TOMI RISC-based baseband ⁇ -controller 322 from standard baseband FLASH memory 323.
  • baseband low-level Bluetooth protocol parts
  • Bluetooth interface 320 may be provided as a standard module and may be connected to external Bluetooth antenna 310 such that the antenna is not part of the module, and is preferably connected to "master" CPU 330 via either a USB or via standard asynchronous serial connection 324 at up to 460.8 kbps.
  • USB may be provided preferably for interfacing larger systems such as, for example, PCs, whereas serial connection 324 is preferably used within embedded systems.
  • Bluetooth radio module 321 and baseband protocol software will preferably be available as separate stand alone products.
  • the Basic mobile WAP-Bluetooth application preferably provided in accordance with the present invention probably requires only moderate communication speeds, but the hardware design should nevertheless be capable of communicating with Bluetooth interface 320 at up to 460.8 kbps in order not to limit the bandwidth requirements of any third-party applications.
  • Bluetooth antenna 310 for Bluetooth interface 320 may be designed in some different ways.
  • Two ways for antenna 310 to be provided for a mobile WAP-Bluetooth server in accordance with the present invention include an antenna provided as a pattern etched directly into PCB 300, or to use an existing Bluetooth antenna "component" as will be illustrated hereinafter.
  • the etched antenna is potentially the most cost-effective solution at virtually zero cost, but may have some drawbacks.
  • An etched antenna may require more PCB space, and could require additional effort to correctly adapt the correct lobe characteristics.
  • a simple passive component which is small, cheap and fairly simple to fit into other designs may be used.
  • master CPU 330 may be required for executing embedded applications, e.g. the Basic mobile WAP- Bluetooth Application or any third party applications.
  • a major requirement for master CPU 330 includes adequate processing-power capabilities to accommodate any possible third-party application processing needs.
  • master CPU 330 should be supported by RS232 interface 335 which may include 2 built-in UARTs to avoid external components for interfacing to Bluetooth interface 320 and RS232 interface 335.
  • Master CPU 330 may further preferably be supported by a powerful and high-quality toolset which may be bundled in the SDK without added cost, and should be available as open-source.
  • the family of master CPU 330 should preferably be easily adaptable and portable to possible future adaptations and should preferably be a member of a family of processors supporting various optional on-chip memory configurations, including both RAM and FLASH memory variants.
  • a number of candidates for master CPU 330 are available on the present processor market, however, one specific processor has been identified as an almost ideal candidate for a mobile WAP-Bluetooth server in accordance with the present invention, namely the AT91 x40xxx manufactured by the Atmel Corporation of San Jose.
  • the Atmel controller family is built around the same processor core as baseband ⁇ -controller 322 in Bluetooth interface 320 providing an advantage in that porting software to possible future processor versions should be greatly simplified.
  • the core of the AT91 x40xxx is a high-performance 32-bit RISC, which should offer more than enough processing power for the types of functionality expected in mobile WAP-Bluetooth applications.
  • the choice of master CPU 330 should be a low-power low-cost design and should offer an excellent code density, i.e. should have low memory requirements for code storage.
  • the AT91 x40xxx family provides such features through its 16-bit "Thumb" instruction set.
  • Atmel AT9I family includes 2 advanced buffered high-speed UARTS built-in, and has various available options for on-chip RAM and FLASH memories. More specifically, a variant which may be preferably for a mobile WAP-Bluetooth server in accordance with the present invention is the AT9I R40807 made by Atmel Corporation of San Jose which features 136kB of zero-waitstate 32-bit on-chip SRAM, but without internal ROM/FLASH.
  • FLASH memories are generally known to have bad availability for purchasing from time to time, therefore it is preferred that the final choice of FLASH memory be made together with any manufacturing sub-suppliers responsible for purchasing FLASH in the required quantities.
  • One choice for FLASH is a 4Mbyte 16 bit- wide in-system-programmable single-plane flash made by Intel Corporation.
  • Such FLASH features a hardware-protectable Boot block which is very well-suited for placement of a bootloader and features a number of 64Kbytes sectors capable of 100.000 erase/write cycles well-suited for both application and data storage, as well as a set of smaller sectors suited for EEPROM- emulation and device parameter storage, e.g. serial number, Mipv6 address, and the like.
  • external SRAM 332 is preferred. External SRAM devices however are unusual in sizes over 512Kbytes, and most are available only in 8-bit wide devices. Therefore, it is preferred that 2 pieces of 8-bit 51 2Kbytes SRAMs are used, resulting in a 1Mbyte 16-bit wide external SRAM. Since another 136Kbytes of zero-waitstate 32-bit SRAM is preferably available on master CPU 330, external SRAM 332 need not be of the fastest and thus most costly type. Instead, standard low-cost 70ns types should be enough.
  • RS232 interface 335 is preferably intended for use between a mobile WAP- Bluetooth server and a host-PC, and should preferably comply with RS232 electrical standards. Compliance could easily and effectively be accomplished by using, for example, a RS232 level converter server, such as, for example, the MAX32xx provided by Maxim Corporation including, for example, a small set of external passive components such as capacitors for charge-pumps.
  • RS232 interface 335 connector should be designed so that a cheap standard "straight-through" serial cable can be used. Accordingly the connector on a mobile WAP-Bluetooth server should preferably be, for example, a 9-pin female D-sub, pin-configured as a DCE.
  • the UARTs which are preferably built into master CPU 330, are of preferably of an advanced buffering type, the use of hardware handshake control lines, i.e. RTS/CTS may be omitted.
  • a mobile WAP-Bluetooth server therefore will preferably always be capable of receiving an uninterrupted stream of high-speed serial data.
  • the RTS/CTS lines should be bridged just behind the connector as is known in the art. Accordingly, the bundled serial cable could preferably be of the absolutely cheapest and lightest type; a straight through cable with only three conductors.
  • one single-color LED is preferably require to be used in a mobile WAP-Bluetooth server in accordance with the present invention.
  • Such an LED may be used to indicate to a user a number of conditions such as, for example, Power-on, Failure, State-of-operation and the like. While the color of the LED can be flexible, it is preferably - blue.
  • the LED is preferably a surface mounted component however a hole fitted or light conducted alternatives could also be used depending on the mechanical design. Since the LED is intended for multi- purpose use, it should be under software control, i.e. it should be controlled from an output pin of master CPU 330.
  • a processor for master CPU 330 in accordance with the present invention may preferably features that output pins could also be under timer-control such that an LED could be flashed at a controlled frequency with on-chip timer support. Further, the intensity of the LED could conveniently be adjusted by using the timer to, for example, PWM-control the LED as is known in the art.
  • a mobile WAP-Bluetooth server might be marketed in a number of countries with varying high- voltage regulations, it is preferred that an external high- voltage power supply 340 be used purchased off-the-shelf and bundled as part of the mobile WAP-Bluetooth server delivery without any further modifications.
  • a mobile WAP-Bluetooth server might be used in more than one place.
  • a mobile WAP-Bluetooth server could normally be used in a shopping area, but for maintenance it could be brought into an office to connect to a PC. Therefore, it would be preferable to accommodate standard power supplies. Standard power supplies however come in different voltages of typically 4.5 to 12V, and with different polarity in the power plugs.
  • the circuits in the mobile WAP-Bluetooth server hardware require a stabilized 3.3V to operate correctly. Therefore voltage regulation within the mobile WAP-Bluetooth server would be preferred. Accordingly, it is preferred that an internal power supply capable of transforming cheap unstabilized 4.5 to 12V input voltages to a stable 3.3V on-board voltage is used.
  • Maximum current required by a mobile WAP-Bluetooth server may be in the range of 300mA. However, at times Bluetooth interface 320 may use approx 300mA itself, while 50mA is specified as typical. Thus to avoid an under dimensioned power supply, a top current of approximately 500mA is preferred.
  • the power connector for power supply 340 may preferably be a standard 2.1mm power connector, with positive power connected to the center of the connector which is the most usual configuration found.
  • the input to power supply 340 should be equipped with protection for reversed polarity and over voltage inputs. Protection for abnormal current consumption, e.g. an automatically "healing" Polyfuse, and ESD protection including through cable transmitted EMC should also preferably be included.
  • PCB Printed Circuit Board
  • the PCB space should not be over dimensioned space limitations should preferably be addressed using multilayer boards, e.g. 4- or 6-layer PCBs, and/or double-sided mounting. Since the material in the PCB could influence the characteristics of the Bluetooth antenna, cheaper PCB materials should be avoided. Therefore, the PCB material should be approved by, for example, RF-design specialists and should be suitable for optimal RF characteristics.
  • a reset-generating voltage supervising server should be used.
  • the reset should be routed to master control 330, FLASH memory 331, and Bluetooth interface 320.
  • the core of baseband ⁇ -controller 322 preferably features built-in support for JTAG debugging, using a standardized 2x10 pin connector. Though not needed for normal use, such a debugging feature may be highly valuable for advanced error-tracing and debugging of prototypes.
  • the debugging lines are made available as "pads" on the PCB, so that a JTAG connector could easily be soldered in by hand when needed.
  • the PCB should be mounted a shielded enclosure. Shielding should preferably cover the power supply 340, the master CPU 330, Bluetooth interface 320 and external memories 331 and 332, since these components are anticipated to be potential problem sources of radiated emissions. However, if the EMC test indicates that shielding is not needed, the shield should not be mounted in order so save component and manufacturing cost.
  • various components of a mobile WAP-Bluetooth server in accordance with the present invention could be integrated into ASIC 420.
  • baseband controller 422, and FLASH 420 could be integrated together.
  • Radio interface 430, power supply 440, antenna 410, LED 423, and RS232 port 450 could be provided as external components on PCB 400. Operation would be virtually the same as described herein above with reference to FIG 3 with the possibility of improvements in speed and the like that normally accompany such integration.
  • mobile WAP-Bluetooth server may be provided with software features as described herein below. Since the mobile WAP-Bluetooth server is preferably intended to provide a software development platform for third parties, limited WAP capability is provided. Such capability may preferably be provided by third party applications. The goals of the software environment preferably make it possible to download new software, to use as much open source software as possible, and the like.
  • the software environment may be divided into the following components as illustrated in FIG 5A. The three basic components are: basic mobile WAP-Bluetooth application 520, software platform 510, and boot loader 530.
  • Basic mobile WAP-Bluetooth application 520 may implement the WAP functionality of the mobile WAP-Bluetooth server software package.
  • the purpose of Basic mobile WAP-Bluetooth application 520 is preferably to implement enough functionality to make a mobile WAP-Bluetooth server an appealing product out-of- fhe-box, but may also serve as an application example for third party developers.
  • the functionality of basic mobile WAP-Bluetooth application 520 is preferably to establish contact with WAP capable clients using Bluetooth stack 513, when such clients enter within the range of Bluetooth interface 320.
  • Basic mobile WAP- Bluetooth application 520 may further send static WAP information to clients stored together with the application in, for example, WMLC format, i.e. precompiled WAP binary format.
  • Basic mobile WAP-Bluetooth application 520 may further provide for disconnecting from clients when static information has been sent.
  • Basic mobile WAP-Bluetooth application may still further support downloading of WAP information by implementing a downloading protocol enabling a host to download individual WMLC files. If a new file is downloaded, the previous file is overwritten.
  • This functionality may be provided in basic mobile WAP-Bluetooth application 520 such that third party developers may implement a more advanced file system without changing the bootloader.
  • Basic mobile WAP-Bluetooth application 520 may further support reset of the mobile WAP-Bluetooth server and preferably needs to be able to receive a RESET command and pass it to the bootloader. Otherwise, a customer may have to manually reset the mobile WAP-Bluetooth server when downloading new applications, for example, from the mobile WAP-Bluetooth website.
  • a mobile WAP-Bluetooth server is preferably limited to contact with seven clients simultaneously which limitation derives directly from the Bluetooth standard, supra. Morever, a limited number of different WAP clients may be supported by basic mobile WAP- Bluetooth application 520 with the number expected to increase as specific information on how to establish a connection with each WAP client is provided on establishing contact with, for example, Ericsson WAP clients, Nokia WAP clients, and the like. It should further be noted that basic mobile WAP-Bluetooth application 520 is preferably configured to support only enough of the WAP protocol to be able to send static WAP information to the WAP client. Basic mobile WAP-Bluetooth application 520 is preferably written in a version of ANSI C licensed using a open source license, e.g. GPL, to be included in the SDK.
  • GPL open source license
  • Software platform 510 preferably implements the core functionality of the mobile WAP-Bluetooth server software package, i.e. the ability to communication using Bluetooth. Software platform 510 thus is expected to be used by most third party developers who are attracted by Bluetooth capabilities associated with the mobile WAP-Bluetooth server.
  • Bluetooth stack 513 is preferably an open source implementation of a Bluetooth stack such as the AXIS Bluetooth stack provided as part of open source Linux operating system. The AXIS Bluetooth stack was originally developed by Axis Communication and wUl preferably be ported to eCos operating system 512, which may be an eCos operating system. For additional information see: developer.axis.com/software/Bluetooth.
  • Bluetooth stack 513 preferably includes HCl, 2CAP, SDP, and RFCOMM layers and may be written in ANSI C and may further be licensed using GPL (the copy holder being Axis Communications) and may be included in the SDK.
  • Operating system 512 is, as previously indicated, preferably eCos, a highly configurable embedded open source operating system developed by Cygnus, currently owned by Red Hat. Using eCos does not directly add any end customer value, but may be included to assist third party developers during development of applications to the mobile WAP-Bluetooth server. For more information see: sourceware.cygnus.com/ecos . Operating system 512 may further preferably provide standard operating system features, such as threads, timers and queues, drivers for hardware, e.g. the serial communication port and the like. Operating system 512 preferably supports master CPU 330 in general but eCos may not support, for example, the ATMEL ATM7TDI processor.
  • eCos will preferably be configured to support this processor with help from the open source community.
  • eCos is licensed using RHEPL (Red Hat eCos Public License) and may further be included in the SDK.
  • the RHEPL license is a slightly stricter version of GPL, e.g. it gives the provider the right to distribute applications using eCos without releasing the source code.
  • the mobile WAP-Bluetooth server software package further preferably provides drivers 511 for different hardware, e.g FLASH memory.
  • drivers 511 are preferably accessible to third party developers even if they decide, for example, not to use the eCos operating system.
  • Drivers 511 are preferably written in ANSI C, may be licensed by GPL with the hardware provider as the copy holder, and are preferably included in the SDK.
  • Bootloader 530 is preferably a small standalone application residing in
  • FLASH memory may be responsible for, for example, initializing the mobile WAP-Bluetooth server, e.g. memory setup and the like, performing basic error detection, e.g. memory check and the like, downloading new applications into RAM, saving applications from RAM to FLASH, and starting the currently stored application.
  • Bootloader 530 preferably has knowledge of memory map 540 of the mobile WAP-Bluetooth server as is illustrated in FIG 5B.
  • data area 541 may include starting address 0x40 00 00 hexadecimal and may end at Address 546, which address may be configurable by a developer.
  • Memory map 540 may further include application area 548, configuration area 543, and boot area 544 which may be configured at base address 545 at address 0x00 00 00 hexadecimal.
  • Boot area 544 may be configured to hold bootloader 530 itself and may be protected by hardware and thus cannot be updated.
  • Configuration area 543 may hold configuration parameters, such as, for example, part numbers, user identification, and the like. Configuration area 543 may be updated by bootloader 530.
  • Application area 542 may be configured to hold one application. If a developer upgrades the application, the prior application may be overwritten. Application area 542 may be updated by bootloader 530.
  • Data area 541 is preferably unreachable from bootloader 530 and may be updated by the application. Accordingly, it may be possible for third party developers to implement flash file systems on the mobile WAP-Bluetooth server.
  • Bootloader 530 may preferably communicate with the development platform using a bootloader protocol. Bootloader 530 may also contain a gdb stub as previously described making it easy for third party developers to debug applications using the gdb debugger.
  • Bootloader 530 may be written in ANSI C and may be provided as part of the SDK.
  • a web site may be included within the overall system mobile WAP-Bluetooth architecture.
  • a developer's website e.g. developer .mobile WAP-Bluetooth.com containing, for example, a project charter, i.e. a description of the mobile WAP-Bluetooth project, downloadable software packages, a third-party developer mailing list, FAQs, project documentation in HTML format, links to related sites, and the like.
  • WAP-Bluetooth web site preferably has two target groups including mobile WAP- Bluetooth application users and third party developers.
  • the basic mobile WAP- Bluetooth application 520 will preferably be supported as a proprietary product however maintenance and support of the mobile WAP-Bluetooth SDK will also be provided, for example, by email notification and through the web site.
  • third party developers are preferably expected to contribute material and peer support. Further in accordance with exemplary embodiments of the present invention, third party applications will not be supported by the equipment provider.
  • the mobile WAP-Bluetooth web site is preferably the main repository for mobile WAP-Bluetooth project documentation and for customer support.
  • Some support will be offered at the point of sale with primary support be offered preferably at the mobile WAP-Bluetooth web site.
  • primary support be offered preferably at the mobile WAP-Bluetooth web site.
  • Also avaiable at the mobile WAP-Bluetooth website will be the mobile WAP-Bluetooth application WAP tool, user-friendly interface with, for example, integrated downloading facilities.
  • an inexperienced user may be enabled to easily construct a WAP page for his mobile WAP-Bluetooth server.
  • Info/news may be provided as well as support, product documentation, FAQ, and links to additional support, for example, for open source components.
  • a SDK may be provided and used for development of software for the mobile WAP-Bluetooth server.
  • the SDK is preferably targeted for internal and external developers.
  • Initial developers may use the SDK for initial development of, for example, the mobile WAP-Bluetooth basic mobile WAP-Bluetooth application 520 while third party developers may use the SDK for independent development of mobile WAP-Bluetooth applications.
  • a development platform may be used for iterative development of an application and may not necessesarily include the mobile WAP-Bluetooth server.
  • the development platform must resemble the target operating environment sufficiently to allow completed applications to be ported to the target hardware, e.g. the mobile WAP-Bluetooth server.
  • the development platform may include a standard PC running, for example, either Linux or Windows 9x NT 2000. If a developer is using Windows 9x certain restrictions may apply, e.g. it is not possible to build a cross-compiler.
  • the development environment may include necessary software tools running on the development platform to support the development, e.g. a compiler, a debugger, and the like.
  • the target platform is preferably the mobile WAP- Bluetooth server which may be coupled to the development platform using, for example, an RS232 connection.
  • the SDK preferably includes a collection of software tools, e.g. the development environment, documentation, and examples derived from previous successful and model developed software for the target platform.
  • the development environment provided with the SDK preferably includes the GNU development environment to allow development of software for the target platform.
  • the GNU development environment consists of two different sets of tools: tools for the development platform, i.e. tools used to produce programs that execute on a standard PC, and tools for the target platform, i.e. tools used to produce programs that execute on mobile WAP-Bluetooth server and the master- CPU in particular.
  • Development platform tools may preferably consist of components such as a gcc compiler, a gdb debugger, a make utility, and a Unix shell, e.g. bash. If the development platform is running Linux, tools are preferably installed together with the operating system, and are not considered part of the SDK.
  • the SDK will preferably contain the CygWin development environment, which is a Win32 open source version of the GNU development environment. CygWin is distributed in binary format, but a developer may download source code if necessary. For more information see: sourceware.cygnus.com/cygwin.
  • Tools for the development platform preferably serve two purposes. Tools may serve to build the tools for the target platform. The tools for the target platform may be found on the Internet in source code format and need to be compiled or built for a specified target platform, e.g the ARM CPU. Tools may further serve to support development of software for the target platform, e.g. the make utility is used when building software.
  • Tools for the target platform preferably consist of components such as the gcc compiler and the gdb debugger whose purpose is for building and debugging software for the target platform.
  • Tools such as gcc and gdb will preferably be included in the SDK both as executable files for Linux and Windows and as source code.
  • Master CPU 330 for example, when embodied, for example, as an ARM7TDMI processor is capable of executing code in two different modes, ARM mode and Thumb mode. These two modes currently require two different sets of development tools thus the SDK will preferably include both sets of tools.
  • the SDK will also preferably contain, apart from the development environment, the following tools: a WML to WMLC compiler, and a tool for downloading applications and data to the mobile WAP-Bluetooth server. It should be noted that if the mobile WAP-Bluetooth server contains a gdb-stub in FLASH memory, such a tool for downloading may be the gdb debugger.
  • the software components in the SDK include the basic mobile WAP-Bluetooth application 520 and software platform 510. While Bootloader 530 may be part of the SDK one reason for excluding it is that since bootloader 530 can not be updated by the third party developer there is no reason to publish the source code.
  • Bootloader 530 preferably does not contain, for example, any know-how that a equipment provider wants to protect. Further, it should be noted that if bootloader 530 contains a modified gdb-stub it should be published since gdb is licensed using GPL.
  • Operating system 512 for example, when provided as eCos may be distributed in the SDK as an installation file which installs the operating system for a number of different target platforms. Configuration tools may further be provided, which are used for configuring eCos for a specified target platform. The result of installation and configuration is a "build" directory containing all source code files needed for the specified target platform.
  • the SDK will preferably, apart from the complete installation of eCos, contain the build directory for the mobile WAP-Bluetooth server.
  • the purpose of documentation is to support third party developers using the SDK.
  • the documentation may contain the following parts: Documentation on how to use the development environment, documentation on other software tools, and documentation on software components. It should be noted that the amount of documentation necessary may not be the same for the different component, e.g. eCos is delivered with a very good documentation that will preferably be included in the SDK. It is further preferably that the documentation format is readable on all supported platforms, e.g. Windows and Linux. Writing documentation in Microsoft Word, for example, can be acceptable if it is also distributed in HTML and Acrobate PDF format.
  • the SDK preferably further contains examples and application notes to support the third party developer.
  • Each example should preferably contain the following parts: commented and well-structured source code, binary file for direct downloads to mobile WAP-Bluetooth server, and a short description in a text file.
  • the complexity of the examples may range from simple "helo world" type applications to a complete mobile WAP-Bluetooth application.
  • the SDK will preferably be developed and packaged according to the Linux common practice, according to, for example, the "Software Release Practice HOWTO", see metalab.unc.edu/LDP/H0WTO/Software-Release- Practice, html).
  • Packaging practice includes: delivery of all software in source code format, and, where applicable, in binary format also for all supported platforms; delivery of all software in compressed format; delivering source code capable of being built using the familiar "./configure; make; make install” sequence implying that the SDK must preferably be made using autoconf and automake; naming of all deliverables according to Linux common practice; including standard top-level files, e.g. README. INSTALL and FAQ in all SDK deliverables.
  • COMP Name of software component e.g. gcc VERSION Version or date of component, e.g. 1.2.3 or 991223
  • ARCH Archive and compression extension e.g tar.gz
  • an Ethernet interface could be useful in some applications.
  • an Ethernet interface would be useful in mobile WAP-Bluetooth applications where the mobile WAP-Bluetooth server needs to be connected to the Internet in order to receive constantly updated information.
  • An Ethernet interface could further be useful for handling many mobile WAP-Bluetooth servers in a network configuration where a wider area is desired to be covered or where information should be shared between mobile WAP-Bluetooth servers. It should be noted that adding an Ethernet interface would require some extra components, such as an Ethernet controller, an isolation server, and a connector. While adding such additional components is possible, space on the mobile WAP-Bluetooth server PCB may be somewhat limited, Thus, an Ethernet interface may preferably be provided in the context of an upgrade to the mobile WAP-Bluetooth server for additional cost.
  • serial interface 450 for example, being configured as an RS232 port, it may also be configured as USB interface.
  • Replacing the RS232 interface with an USB-slave interface could be advantageous as a further potential upgrade since virtually all modern PCs today support the IJSB interface, and the bandwidth offered is substantially higher than on an RS232 port.
  • the mobile WAP-Bluetooth server could receive power from the USB host, thereby omitting the need for an extra power supply. It should be noted that while the above configuration is possible, the mobile WAP-Bluetooth server, in order to derive power from the USB host would be required to draw no more than a maximum of 50mA.
  • USB slave interface in the mobile WAP-Bluetooth server, software drivers are necessary. It should still further be noted that the amount of components, PCB space, and cost associated with providing an USB slave interface is approximately within the same range as for providing the RS232 interface.
  • voice/music information is preferably either fairly short, or voice/music information preferably is provided from an external server via an interface, e.g. RS232, Ethernet, or USB.
  • Adding audio capabilities to the mobile WAP-Bluetooth server is possible preferably by adding only a few extra components requiring only moderate extra PCB space with minimal component cost.
  • video may further be provided as long as certain system parameters are met. For example, WAP version 2.0 or later must be used and the mobile WAP-Bluetooth terminal must be capable of entering a graphics mode on its local display. Accordingly a graphics driver must be present on the mobile WAP-Bluetooth terminal.
  • One way of handling varying memory demands includes adding a "memory expansion slot" to the mobile WAP-Bluetooth server, thus enabling a user to, for example, insert a memory card or appropriate memory expansion module with an amount of memory appropriate for the application.
  • each type of memory device may have memory different capacity in the amount of from several to several hundreds of megabytes and several "standards”, e.g. "MemoryCard”, “FlashStick”, and "PC-Card” exist which must be supported.
  • the mobile WAP-Bluetooth server may be equipped with a USB master interface which interface may be used to connect USB peripherals with the needed resources to the mobile WAP-Bluetooth server, thereby avoiding the need to add extra hardware like Ethernet and memory slots directly to the hardware.
  • a USB master interface is a significantly more complex interface than its "slave" counterpart.
  • the USB standard is designed to provided for cheap and simple slaves by putting the cost and complexity on the master side, which is expected to be a server in the range of a PC.
  • the USB master requires a few rather expensive components, but the most complex part would be the USB master software stack, which is both complex and potentially memory-demanding.
  • the mobile WAP-Bluetooth server is preferably battery- powered, particularly if there is no specific need to have it continuously connected by a wire to a wall outlet.
  • a batter powered mobile WAP-Bluetooth server design would benefit from hardware configured for low-power-mode support, however, such support is provided by fairly complex "power-management" software which is not part of the standard software load.
  • extra components are needed, most notably a battery adding considerable implications to the cost and space requirements associated with the mobile WAP-Bluetooth server.
  • a mobile WAP-Bluetooth server is preferably designed for indoor "office” conditions. Therefore, in order to use the mobile WAP-Bluetooth server in outdoor applications, of which there are potentially many, and also "industrial” applications where hostile environmental conditions may exist, existing design must be altered. "Outdoor” use might include use under extremely wet, extremely dry, extremely cold, extremely hot, and/or extremely dusty, dirty, or otherwise where conditions of fine particulate matter is present. Accordingly, the mechanical design would need to be modified to suit the particular application or range of expected environmental conditions.
  • the normally packaged mobile WAP-Bluetooth server is expected to perform normally down to approx +5degC.
  • Bluetooth interface 320 is presently available in commercial temperature range only. This can be expected to change over time with improved Bluetooth interface module coming into production as the popularity and corresponding demand for mobile WAP-Bluetooth servers and devices increases. "Industrial" use might further mean that the mobile WAP-Bluetooth server could be exposed to, for example, vibrations, fluctuating temperatures, and harsh electromagnetic fields, none of which are handled in the standard commercial design.
  • Several problems related to industrial and outdoor use could be handled at once by designing a more "rugged” mechanical packaging, which is, for example, shock and vibration proof, water proof, dust proof, and resistant to temperature extremes, but it might also have implications for the hardware design.
  • interfaces like RS232 which are connected to industrial equipment are galvanically isolated from each other. It shouuld further be noted that in accordance with ruggedized and batterpowered units for use in remote industrial and/or outdoor applications, the use of a solar panel to maintain a battery charge would also be useful. Since it is possible to envision a number of different combinations of requirements it may be useful to consider variants separately for each intended requirement specification rather than a single mobile WAP-Bluetooth server for all possible physical conditions. As previously noted, the RS232 interface could either be exchanged with another interface such as, for example, an USB-slave, or completely removed. Maintenance work intended to be carried out over it might instead be transferred via the Bluetooth interface itself.
  • Removing the components for the RS232 would save some PCB space mostly from the vicinity of the connector, and possibly also some degree of costs. Although the RS232 interlace is not very costly, removing the RS232 interface might have a few implications worth noting.
  • the RS232 connector in one embodiment is used for anchoring the PCB into the enclosure. Removing the RS232 connector would then imply that the PCB must be anchored in a different way.
  • the RS232 line is used for debugging during application development. Thus, if the RS232 connector is removed, a different way of providing debugging support must be included in the SDK and in the mobile WAP-Bluetooth server. Possible solutions might include, for example, a simple two-pin SIP connector.
  • the / ⁇ -controller for use with, for example, master CPU 330 or baseband ⁇ -controller 322, 422, e.g. ARM7TDMI comes in a family which offers a maximum combination of 2Mbyte FLASH + 136Kbyte of SRAM memory in one single package.
  • the Bluetooth antenna component may further be desirable in accordance with various exemplary embodiments of the present invention, to exchange the Bluetooth antenna component with a pattern on the PCB.
  • the Bluetooth antenna component is a rather low-cost component, it could be completely removed if an antenna was realized as a pattern directly into the PCB. Such a solution would take some effort to correctly design, but once designed it would mean that the antenna would come virtually at zero marginal cost.
  • an exemplary embodiment including antenna component provides a compact solution while a PCB variant is anticipated to require somewhat more PCB space.
  • Bluetooth interface 320 is a complete embedded microcomputer, having both powerful baseband / x-controller 322 and FLASH memory 323.
  • Bluetooth interface 320 is stand-alone priced at around US$30, which is a considerable portion of the total mobile WAP-Bluetooth server product cost. It is further now understood that only around 30% of the capacity of baseband ⁇ -controller 322 in Bluetooth interface 320 is used for Bluetooth related communication, and that the remainder of the capacity is intended for end-user applications. However, since the baseband software has not yet been "packaged" so that it can safely coexisting on a single CPU together with an end-user application, the additional capacity is not presently available though it is expected that this problem will soon be solved in due course.
  • both the external master CPU 330 and external memories 331 and 332 could potentially be removed from the PCB. Doing so presents an attractive solution for high- volume second generation of the mobile WAP-Bluetooth hardware, for example as embodied on PCB 400 as illustrated in FIG 4, considerably reducing cost, PCB space, and power consumption of the mobile WAP-Bluetooth server. Moreover, simple migration to a single-CPU solution is provided for in a two processor design.
  • Extended mobile WAP-Bluetooth application functionality may be provided in accordance with the present invention by providing additional features such as for example, an Embedded Flash File System and/or EEPROM emulation.
  • An embedded flash file system is preferably part of software platform 510 simulating an ordinary file system, e.g. DOS, using FLASH memory.
  • mobile WAP-Bluetooth may implement the following functionality. With an embedded flash file system more than one file with WAP contents may be saved allowing, for example, the possibility of sending different information to different clients. With an embedded flash file system better information security may be added since each file may be given, for example, security access attributes, thus preventing anyone from updating the information.
  • embedded flash file system file security may be added in the form of, for example, crash recovery. It should be noted that embedded flash file systems may be available as commercial products although the mobile WAP-Bluetooth server, in various exemplary embodiments in accordance with the present invention may be provided with enough FLASH memory to support an embedded flash file system.
  • EEPROM emulation may be used for storing small pieces of information in, for example, FLASH memory 331, 421. Accordingly, FLASH memory 331, 421 may be configured to act as EEPROM memory which may be useful if, for example, basic mobile WAP-Bluetooth application 520 is updated to store certain information elements, e.g. how many successful Bluetooth connections have been made during a particular time period, which time period may also be stored.
  • TCP/IP stack may be required for converting mobile WAP-Bluetooth server into a web server/gateway using, for example, the Ethernet connection as previously described. It should be noted that it may further be possible to add TCP/IP functionality to both the Bluetooth connection and the RS232 connection. It should further be noted that a TCP/IP stack is preferably included as a component of the eCos operating system for use as operating system 512, however, other open source and commercially available alternatives may also be available.
  • Extended functionality of Bluetooth stack 513 may preferably be provided on an ongoing basis. Consequently, software platform 510 preferably must be updated periodically until the such a time that Bluetooth stack 513 is considered finished. Software platform 510 may be updated periodically despite whether or not Bluetooth stack 513 extensions have been released. For, example, if any kind of new software functionality is added, e.g. support for new client profiles, which makes it possible to implement new and interesting functionality in mobile WAP- Bluetooth environment, software platform 510 might also be updated.
  • an embedded web server may further be desirable in accordance with various exemplary embodiments of the present invention, and may have different consequences depending on whether the embedded web server is added to a Bluetooth connection, an RS232 connection, or both.
  • Web support added to a Bluetooth connection may be used to convert the mobile WAP-Bluetooth server into a web server for Bluetooth and web capable clients such as for example, a PDA or laptop computer.
  • Web support added to the RS233 connection makes it possible for the mobile WAP-Bluetooth server to operate as a WAP server for shifting data between the Internet and a WAP client.
  • While mobile WAP-Bluetooth service may be partially maintained, for example, by downloading new WAP contents using a web browser on the host, only those maintenance features supported by basic mobile WAP-Bluetooth application 520 can be supported with an embedded web server.
  • Maintenance features supported by bootloader 530 may not be supported by an embedded web server.
  • an embedded web server may require the addition of a TCP/IP stack to software platform 510. As previously noted TCP/IP stacks may be available as both open source and commercial products.
  • a web interface to bootloader 530 would make it possible to perform maintenance such as basic diagnostics and the downloading of new applications using a web browser on the host.
  • the mobile WAP-Bluetooth maintenance web page could be located locally in the mobile WAP-Bluetooth server or could be connected remotely through a host interface to a main mobile WAP-Bluetooth website for remote maintenance.
  • the bootloader web interface may require the addition of a TCP/IP stack to software platform 510.
  • a complete WAP stack implementation would add WAP functionality such as support for security transactions and the possibility of implementing, for example, a WAP gateway. It should be noted that complete WAP stacks may be available as commercial products.
  • EL/LX Application Programming Interface
  • EL/LX Application Programming Interface
  • Linux applications such as, for example, the Axis bluetooth stack would be greatly simplified. See, for example, sour ceware.cy gnus, com/ elix for more information.
  • eCos operating system is implemented in C+ + language and not in C language.
  • eCos contains C wrapper code making it possible to implement applications in C.
  • basic mobile WAP-Bluetooth application 520 and Bluetooth stack 513 are implemented in C language. If the functionality of basic mobile WAP-Bluetooth application 520 is dramatically extended it may be advisable to shift to an object oriented programming language, such as C+ + . Doing so will require C + + wrapper code for code written in C, e.g. Bluetooth stack 513.
  • High-level language interpretation support may further be provided in accordance with various exemplary embodiments in accordance with the present invention.
  • a high-level interpreted language may be implemented in mobile WAP-Bluetooth server, e.g. Java, Pert, or Python.
  • mobile WAP-Bluetooth server e.g. Java, Pert, or Python.
  • an equipment provider preferably must implement a language interpreter or adapt an open source implementation of the mobile WAP-Bluetooth server.
  • All functionality necessary for third party developers such as, for example, Bluetooth functionality, must be provided as an mobile WAP-Bluetooth library of functions. Accordingly the addition of high- level language interpretation makes the mobile WAP-Bluetooth server an extremely easy platform for developing and implementing an increasingly diverse array of new Bluetooth functionality.
  • basic mobile WAP- Bluetooth application 520 may be implemented preferably in less than 50 lines of code. It should further be noted that the mobile WAP-Bluetooth server could fairly easily be implemented in a cellular phone.
  • a user scenario 600 may be provided in accordance with exemplary embodiments of the present invention where a mobile WAP-Bluetooth server 610 may be used, for example, by a tour guide conducting a guided tour of a typical sight, such as for example, London's Big Ben.
  • mobile WAP-Bluetooth te ⁇ ninals 620 may be provided with push services, such as, for example, cards 621 as may be further explained in "WAP - The wireless application protocol", supra, which cards 621 may be associated with the sight, e.g. Big Ben.
  • Push services therefore may be provided from mobile WAP-Bluetooth server 610 to mobile WAP-Bluetooth terminals 620 over Bluetooth air interface 611.
  • mobile WAP-Bluetooth server 710 may maintain a connection to mobile network 730 via antenna 731 throughout a wide area while providing mobile WAP- Bluetooth server oriented services to mobile WAP-Bluetooth terminals 720 remaining within Bluetooth coverage area 711.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé et un appareil permettant de fournir aux clients d'un environnement WAP Bluetooth des services d'informations en fonction de la localisation. Des unités serveur à protocoles d'applications sans fil (WAP) Bluetooth mobiles sont fournies aux clients, y compris aux développeurs troisième partie qualifiés. Un kit développeur de logiciel (SDK) WAP Bluetooth est fourni aux développeurs troisième partie et des applications WAP Bluetooth qualifiées sont ainsi développées. Des applications qualifiées sont chargées sur des unités serveur WAP Bluetooth mobiles pour fournir des services d'informations en fonction de la localisation. Des connexions sont établies avec des terminaux clients WAP Bluetooth et les pages WAP en fonction de la localisation sont poussées en direction des terminaux client WAP Bluetooth à l'aide d'une application WAP Bluetooth. Un signal WAP Bluetooth est transmis dans une zone de couverture associée au service d'informations fonction de la localisation et des connexions sont établies avec des terminaux clients pour fournir le service d'informations fonction de la localisation. Des applications qualifiées sont enregistrées de telle manière que les applications sont disponibles aux clients et aux développeurs troisième partie dans un registre produits. Des applications qualifiées sont présentées et fournies à titre expérimental aux clients utilisant un site web. Le kit SDK comporte un environnement de développement WAP Bluetooth, des modules logiciel WAP Bluetooth, des exemples d'applications WAP Bluetooth, et une documentation.
PCT/SE2001/001742 2000-08-16 2001-08-10 Procédé et appareil permettant de fournir un serveur wap mobile WO2002015075A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001280391A AU2001280391A1 (en) 2000-08-16 2001-08-10 Method and apparatus for providing a mobile wap server

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US63910200A 2000-08-16 2000-08-16
US09/639,102 2000-08-16

Publications (2)

Publication Number Publication Date
WO2002015075A1 true WO2002015075A1 (fr) 2002-02-21
WO2002015075B1 WO2002015075B1 (fr) 2002-07-18

Family

ID=24562729

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2001/001742 WO2002015075A1 (fr) 2000-08-16 2001-08-10 Procédé et appareil permettant de fournir un serveur wap mobile

Country Status (2)

Country Link
AU (1) AU2001280391A1 (fr)
WO (1) WO2002015075A1 (fr)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004032378A1 (fr) 2002-10-03 2004-04-15 Dai Nippon Printing Co., Ltd. Systeme de gestion de communication, dispositif terminal mobile et programme de gestion de communication
WO2006111782A1 (fr) * 2005-04-19 2006-10-26 Nokia Corporation, Procede, dispositif et systeme de commande de l'introduction d'une application dans un dispositif de terminal mobile
US7263086B2 (en) 2002-11-12 2007-08-28 Nokia Corporation Method and system for providing location-based services in multiple coverage area environments
US7366523B2 (en) 2002-11-12 2008-04-29 Nokia Corporation Method and system for providing location-based services
US7469232B2 (en) 2002-07-25 2008-12-23 Sony Corporation System and method for revenue sharing for multimedia sharing in social network
US7603406B2 (en) 2002-07-25 2009-10-13 Sony Corporation System and method for wireless software download and remote transaction settlement
CN102984341A (zh) * 2005-04-19 2013-03-20 诺基亚公司 控制移动终端设备中应用启动的方法、设备和系统
US20220360739A1 (en) * 2007-05-14 2022-11-10 BlueRadios, Inc. Head worn wireless computer having a display suitable for use as a mobile internet device

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999045732A1 (fr) * 1998-03-03 1999-09-10 Telefonaktiebolaget Lm Ericsson (Publ) Procede, configuration et appareil destines a la fourniture d'informations

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999045732A1 (fr) * 1998-03-03 1999-09-10 Telefonaktiebolaget Lm Ericsson (Publ) Procede, configuration et appareil destines a la fourniture d'informations

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
"Ericcson Press Releases; Ericsson launches first Bluetooth Development Kit", Ÿ, 11 May 1999 (1999-05-11), pages 1 - 2, XP002159413, Retrieved from the Internet <URL:http://www.ericsson.com/press/archive/1999Q2/19990511-0036.html> [retrieved on 20010202] *
"Specification of the Bluetooth System; Wireless connections made easy; Core; v1.0B", Ÿ, vol. 1, 1 December 1999 (1999-12-01), pages 1,495 - 516, XP002159412, Retrieved from the Internet <URL:http://www.bluetooth.com/developer/specification/core_10_b.pdf> [retrieved on 20010205] *
ARFWEDSON H ET AL: "ERICSSON'S BLUETOOTH MODULES", ERICSSON REVIEW, SE, STOCKHOLM, no. 4, 1999, pages 198 - 205, XP000877966, ISSN: 0014-0171 *
DATABASE INSPEC [online] INSTITUTE OF ELECTRICAL ENGINEERS, STEVENAGE, GB; ASAMI S: "The FreeBSD Ports Collection", XP002159414, Database accession no. 6490522 *
ERLANDSON C ET AL: "WAP - THE WIRELESS APPLICATION PROTOCOL", ERICSSON REVIEW, SE, ERICSSON STOCKHOLM, no. 4, 1998, pages 150 - 153, XP000792053, ISSN: 0014-0171 *
MEYER E: "DAS BLUETOOTH- KONZEPT", FUNKSCHAU, FRANZIS-VERLAG K.G. MÜNCHEN, DE, vol. 72, no. 9, 16 April 1999 (1999-04-16), pages 34 - 38, XP000894050, ISSN: 0016-2841 *
PROCEEDINGS OF THE FREENIX TRACK. 1999 USENIX ANNUAL TECHNICAL CONFERENCE, PROCEEDINGS OF THE FREENIX TRACK. 1999 USENIX ANNUAL TECHNICAL CONFERENCE, MONTEREY, CA, USA, 6-11 JUNE 1999, 1999, Berkeley, CA, USA, USENIX Assoc, USA, pages 193, ISBN: 1-880446-32-4 *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7469232B2 (en) 2002-07-25 2008-12-23 Sony Corporation System and method for revenue sharing for multimedia sharing in social network
US7603406B2 (en) 2002-07-25 2009-10-13 Sony Corporation System and method for wireless software download and remote transaction settlement
WO2004032378A1 (fr) 2002-10-03 2004-04-15 Dai Nippon Printing Co., Ltd. Systeme de gestion de communication, dispositif terminal mobile et programme de gestion de communication
EP1555770A1 (fr) * 2002-10-03 2005-07-20 Dai Nippon Printing Co., Ltd. Systeme de gestion de communication, dispositif terminal mobile et programme de gestion de communication
EP1555770B1 (fr) * 2002-10-03 2015-03-25 Dai Nippon Printing Co., Ltd. Systeme de gestion de communication, dispositif terminal mobile et programme de gestion de communication
US7263086B2 (en) 2002-11-12 2007-08-28 Nokia Corporation Method and system for providing location-based services in multiple coverage area environments
US7366523B2 (en) 2002-11-12 2008-04-29 Nokia Corporation Method and system for providing location-based services
WO2006111782A1 (fr) * 2005-04-19 2006-10-26 Nokia Corporation, Procede, dispositif et systeme de commande de l'introduction d'une application dans un dispositif de terminal mobile
CN101147387B (zh) * 2005-04-19 2012-09-26 诺基亚公司 控制移动终端设备中应用启动的方法、设备和系统
CN102984341A (zh) * 2005-04-19 2013-03-20 诺基亚公司 控制移动终端设备中应用启动的方法、设备和系统
US9398137B2 (en) 2005-04-19 2016-07-19 Nokia Technologies Oy Method, device and system for controlling application launching in a mobile terminal device
US20220360739A1 (en) * 2007-05-14 2022-11-10 BlueRadios, Inc. Head worn wireless computer having a display suitable for use as a mobile internet device

Also Published As

Publication number Publication date
AU2001280391A1 (en) 2002-02-25
WO2002015075B1 (fr) 2002-07-18

Similar Documents

Publication Publication Date Title
US7536181B2 (en) Platform system for mobile terminals
JP4358738B2 (ja) 移動体端末のための階層アーキテクチャ
US8948184B2 (en) Embedded system development platform
US20040005859A1 (en) Wireless deployment / distributed execution of graphical programs to smart sensors
US20040199897A1 (en) Deployment and execution of a graphical program on an embedded device from a PDA
US20020083322A1 (en) Distribution of deployment information for remote applications
KR100579210B1 (ko) 컴퓨터 시스템에 대한 라디오 모듈을 제공하기 위한 방법및 장치
WO2002015074A2 (fr) Procede destine au developpement d&#39;une application troisieme partie
WO2002015075A1 (fr) Procédé et appareil permettant de fournir un serveur wap mobile
WO2002015076A1 (fr) Procede et appareil destines a des services d&#39;informations fonction de la localisation
CN101800910A (zh) 一种模拟系统、pc侧模拟器及手机侧代理客户端
Noe Design and Implementation of the Communications Subsystem for the Cal Poly CP2 Cubesat Project
JP4241775B2 (ja) 通信装置
Bogdanov et al. Flash programming low power microcontrollers over the Internet
EP1530756B1 (fr) Deploiement sans fil/execution distribuee de programmes graphiques vers des capteurs intelligents
Tang et al. Internet of things security: Principles and practice
KR100943698B1 (ko) 휴대형 통신기기를 위한 확장 장치
El Kouche Wireless sensor network platform for Harsh Industrial Environments
KR100886770B1 (ko) 다기종의 휴대형 통신기기를 위한 확장 장치
Reinhardt et al. Tubicles: Heterogeneous Wireless Sensor Nodes
Wulff et al. Exploring Radio
Auletta et al. Performance evaluation of web services invocation over Bluetooth
Kivelä The design process of an open source mobile phone
Gardeazabal Martínez de Espronceda Testing the performance and feasibility of Bluetooth communications in pervasive systems
CN113138795A (zh) 一种基于sdr的可配置协议通信系统

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: B1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: B1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP