WO2003081428A2

WO2003081428A2 - 'A local area wireless network simulator'

Info

Publication number: WO2003081428A2
Application number: PCT/IE2003/000045
Authority: WO
Inventors: Patrick Connolly; Stephen Crane; Niall Smart
Original assignee: Rococo Software Limited
Priority date: 2002-03-22
Filing date: 2003-03-24
Publication date: 2003-10-02
Also published as: IES20030216A2; IE20030215A1; WO2003081428A3; AU2003219475A1

Abstract

A simulator (1) has virtual stacks (10, 23) which simulate entirely in software behaviour of actual stacks for hardware devices. Stubs (25) are provided for resource-poor applications (21) to communicate with virtual stacks (10). A discovery service (12) simulates in software hardware devices and has a discovery function to discover these simulated devices. It responds to application calls indicating the simulated devices as if they were the actual devices within range, i.e. within a piconet.

Description

" A local area wireless network simulator"

INTRODUCTION

Field of the Invention

The invention relates to development of applications having a capability for communication via wireless local area networks such as Bluetooth.

Prior Art Discussion

At present one of the major problems in developing such an application is that of ensuring that the application effectively communicates with a range of other applications with which it should be compatible. Testing is often time-consuming and it may be limited by the availability of other applications and communication- protocol middleware. The fact that different vendors supply stacks with different characteristics makes development of the wireless communication aspects particularly time-consuming and error-prone. The fact that specific local area wireless network hardware is required to develop such applications also makes this development time-consuming and error-prone.

The invention addresses this problem.

SUMMARY OF THE INVENTION

According to the invention, there is provided a simulator comprising a processor programmed to:

provide virtual stacks each simulating in software an actual local area wireless communication stack for an associated hardware device; and allow each of a plurality of applications under development or test to utilise a virtual stack.

In one embodiment, the simulator comprises a discovery service for locating a simulated device called by an application via a virtual stack.

In another embodiment, the discovery service locates a virtual stack and associated stored device parameters to locate a simulated device.

In a further embodiment, the discovery service informs a calling application that all of the simulated devices are available as if they were actual devices within a piconet.

In one embodiment, the device parameters are stored in a configuration file.

In another embodiment, the simulator further comprises a device editor for allowing a user to edit configuration files.

In a further embodiment, the device parameters are stored in a mark-up language.

In one embodiment, the simulator comprises a surrogate service storing and allowing access to a plurality of virtual stacks.

In another embodiment, the surrogate service stores and allows access to virtual stacks for applications which are too resource-poor to directly interface with a virtual stack.

In a further embodiment, the simulator further comprises virtual stubs for use by said applications when communicating with the virtual stacks In one embodiment, the virtual stacks make calls to discover a simulated device in response to a standard application API call.

In another embodiment, the simulator further comprises a management interface for monitoring dynamic communication between applications and generating a user output indicating such communication.

DETAILED DESCRIPTION OF THE INVENTION

Brief Description of the Invention

The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings, in which:

Fig. 1 is a schematic representation of a simulator of the invention and of applications to which it is connected.

Description of the Embodiments

Referring to Fig. 1 a simulator of the invention is illustrated. The simulator 1 comprises a simulator core 2, in turn comprising a plurality of virtual stacks ("NStacks") 10 in a surrogate service 11, and a discovery service 12. The simulator 1 also comprises, for development of applications :-

virtual stacks ("NStacks") 23 for development of J2SE™ applications; and

virtual stacks stubs ("NStack Stubs") 25 for development of J2ME™ applications. The components 23 and 25 reside outside the core 2.

The simulator 1 further comprises a management interface 30, and a device editor 40 connected to the discovery service 12.

In Fig. 1 the simulator 1 is shown in use by developers developing a J2SE™ application 20 and two J2ME™ applications 21.

The NStacks 10 are simulated software stacks, each associated with a device (e.g. mobile telephone type) simulated by the simulator 1. The NStacks 10 are particularly for the J2ME™ applications 21 which are too resource-poor to support a full stack. However, the applications 21 can utilise the NStack Stubs 25 which allow them to use the NStacks 10.

On the other hand the applications 20 can support a stack and so the simulator 1 provides the VStack 23 locally interfacing with the application 20 under development.

The discovery service 12 is used to allow applications to discover the simulated devices that reside within the simulator. The simulated devices are embodied by the VStacks 10, 23 and their configuration and defining characteristics are recorded in XML files.

The device editor 40 performs configuration of the properties of a simulated device so that the device may be instantiated in a piconet. Examples of these properties are

(i) the user-friendly name of a communications device (ii) the class of device (e.g.

'mobile phone') (iii) the devices preknown (i.e. previously discovered) by this device

(iv) the link-keys required to set up secure communications channels with peer devices. The discovery service 12 simulates the action of the simulated devices in a piconet when one wishes to locate the simulated devices present for the purposes of connecting to a service on one of them. It maintains a registry of simulated devices present and performs the desired search action on each of them on behalf of the initiator (an application 20 or 21).

The management interface 20 is linked with the discovery service 12 and the VStacks in order to represent events of interest in the piconet (e.g. the arrival/ departure of a device, connection status between devices) and to dynamically change the characteristics of devices present in the piconet.

Thus, the simulator simulates a piconet of devices on which the developer may develop applications. The applications under development communicate with each other in a chain including:

- first application 20 or 21 under development or test,

- VStack 23 or 10, for first application;

- discovery service 12 to discover the second application's associated VStack;

- VStack 23 or 10 for the device of the second application, and - the second application 20 or 21.

The simulator 1 allows Java Bluetooth™ application developers to develop and test applications in a simulated environment without the need for them to provide a Bluetooth stack or Bluetooth hardware. The simulator 1 supports Java 2 Platform, Standard Edition (J2SE) and Java 2 Platform, Micro Edition (J2ME) in this embodiment.

The applications 20 and 21 are developed using the standard Java Bluetooth API.

The simulator provides an implementation of this API that simulates Java APIs for Bluetooth Wireless Technologies™ semantics and behaviour without using an actual Bluetooth stack or Bluetooth hardware. The following use cases describe the components involved in both the J2SE and J2ME case.

J2SE Use Case

1. Application 20 is launched in a J2SE Java Virtual Machine - this JVM contains the application components, plus a J2SE VStack 23.

2. The VStack 23 automatically registers the application with the simulator discovery service 12. 3. The application 20 attempts to discover other Bluetooth devices that are in range by making a standard Java Bluetooth API call.

4. This call is implemented by the J2SE VStack 23 - the VStack 23 uses Java RMI to call the discovery service 12.

5. The discovery service 12 maintains a list of all registered (i.e. in-range) devices, and responds to the VStack' s inquiry with a list of appropriate devices, which are in-range, and their virtual addresses.

6. The application attempts to connect to a chosen device by making a standard Java API call.

7. The VStack 23 implements this call by opening an RMI connection to the VStack 10 or 23 of the chosen device - this connection will either be to another JVM containing a J2SE apρlication+ VStack 23, or to the VStack surrogate service 11 containing J2ME VStacks 10 (see J2ME use case below).

8. All messages between virtual devices are now routed directly between peer VStacks. 9. Each VStack represents a virtual device, and the characteristics and configuration of each device are stored in XML configuration files in the service 12.

10. The dynamic behaviour of the interacting applications (including devices in range, connections between devices, messages passed between devices, configuration changes in devices) may be both monitored and controlled via the management interface 30. J2ME Use Case

1. Application 21 is launched in a J2ME Java Virtual Machine - this JVM contains the application components, plus a J2ME VStack stub 25.

2. The VStack stub 25 provides a stripped down client-side version of the NStack 10, which has a small footprint making it suitable for running in a J2ME JNM.

3. The NStack stub 25 communicates with the NStack surrogate service 11. This service launches the matching device NStack, populating it from the appropriate XML configuration record.

4. The NStack stub 25 communicates via XML-RPC with the NStack 10 for simulated virtual Bluetooth device. This NStack 10 resides in the surrogate service 11 in the J2ME case.

5. The NStack stub 25 automatically registers the application 21 with the discovery service 12 via the VStack 10.

6. Application 21 attempts to discover other Bluetooth devices that are in range by malting a standard Java API call.

7. This call is implemented by the J2ME VStack stub 25 - the stub 25 uses XML- RPC to forward the call to the VStack 10, which queries the list of registered devices in the discovery service 12.

8. The discovery service 12 maintains a list of all registered (i.e. in-range) devices, and responds to the VStack' s inquiry with a list of appropriate devices and their virtual addresses.

9. The application 21 attempts to connect to a chosen device by making a standard Java API call.

10. The VStack 10 implements this call by opening a RMI connection to the VStack of the chosen device - this connection will either be to another VStack 10 in the surrogate service 11, or to a JVM containing a J2SE application-i- NStack 23 in the J2SE case. 11. All messages between virtual devices are now routed directly between peer NStacks.

12. Each NStack represents a virtual device, and the characteristics and configuration of each device are stored in XML configuration files. 13. The dynamic behaviour of the interacting applications (including devices in range, connections between devices, messages passed between devices, configuration changes in devices) may be both monitored and controlled via the simulator's management interface 30.

The simulator 1 allows developers to develop and run Java Bluetooth applications without need for a Bluetooth stack or hardware. It also allows J2ME and J2SE Bluetooth applications to co-exist in the same framework. It overcomes the restrictions of J2ME through the NStack stub 25 and XML-RPC mechanism. Also, the simulator 1 allows flexible configuration of virtual devices through the XML configuration mechanism. Another advantage is that it allows dynamic monitoring and updating or the virtual devices.

The invention is not limited to the embodiments described but may be varied in construction and detail.

Claims

1. A simulator comprising a processor programmed to:

provide virtual stacks (10, 23) each simulating in software an actual local area wireless communication stack for an associated hardware device; and

allow each of a plurality of applications (20, 21) under development or test to utilise a virtual stack.

2. A simulator as claimed in claim 1, wherein the simulator (1) comprises a discovery service (12) for locating a simulated device called by an application via a virtual stack (10, 23).

3. A simulator as claimed in claim 2, wherein the discovery service locates a virtual stack and associated stored device parameters to locate a simulated device.

4. A simulator as claimed in claims 2 or 3, wherein the discovery service (12) informs a calling application (20, 21) that all of the simulated devices are available as if they were actual devices within a piconet.

5. A simulator as claimed in claims 3 or 4, wherein the device parameters are stored in a configuration file.

6. A simulator as claimed in claim 5, wherein the simulator (1) further comprises a device editor (40) for allowing a user to edit configuration files.

7. A simulator as claimed in any of claims 3 to 6, wherein the device parameters are stored in a mark-up language.

8. A simulator as claimed in any preceding claim, wherein the simulator (1) comprises a surrogate service (11) storing and allowing access to a plurality of virtual stacks.

9. A simulator as claimed in claim 8, wherein the surrogate service (11) stores and allows access to virtual stacks for applications (21) which are too resource-poor to directly interface with a virtual stack (10).

10. A simulator as claimed in claim 9, wherein the simulator (1) further comprises virtual stubs (25) for use by said applications (21) when communicating with the virtual stacks (10).

11. A simulator as claimed in any preceding claim, wherein the virtual stacks (10, 23) make calls to discover a simulated device in response to a standard application API call.

12. A simulator as claimed in any preceding claim, wherein the simulator (1) further comprises a management interface (30) for monitoring dynamic communication between applications and generating a user output indicating such communication.

13. A computer program product comprising software code for completing a simulator as claimed in any preceding claim when executing on a digital computer.