Using Bluetooth as Passenger Interface

When offering honest advice, make sure you´re halfway out the door.

ne U.S. president (Thomas Jefferson) once said that "That government is best, that governs the least". And the ideal commuter system would be that which inconveniences riders the least. Passengers should not have to put up with queueing, waiting, handling of money, etc., which is the usual experience for commuters today. Many public transport systems around the world are now using "Smart Cards". The 3 main benefits of these cards are that they: can store, and transmit to the system, such information that the passenger use on a daily basis, such as destination and travel route can automatically handle the payment for the fare need not be in direct contact with the card reader equipment.

The Bluetooth technology is eminently suited to this same task. Bluetooth can do all this, and much more, as will be described on this page. The work with development of Bluetooth was started by Ericsson Mobile Communication in 1994, and Bluetooth-units are now gradually entering the market. For a brief technical description of Bluetooth itself, see the Bluetooth page on this website. Passengers travelling with FLYWAY® will notice 3 interfaces with the system where the Bluetooth technology is involved:

When booking or ordering beamcars at station terminals When commandeering beamcars for their use When entering and leaving the beamcars (they might notice the synchronization between the cabin doors and the cubicle doors). This page will deal with each of these 3 interfaces in turn, and also take a look at how the station terminals interact with the rest of the FLYWAY® system. List of contents: Applying Bluetooth to FLYWAY´s passenger interface The Interface between Bluetooth-terminals and the FLYWAY´s station LAN The Interface between passengers and Beamcars The Interface between Beamcars and station cubicles Some Scenarios

1. Applying Bluetooth to FLYWAY´s passenger interface

A "typical" station e will here see how well the Bluetooth technology would fit the needs of an automatic commuter system, by applying it to SwedeTrack´s FLYWAY® system. Let us base our reasoning below on the "typical" FLYWAY®station shown at right (illustration 1:1). It has 4 berths (or individual stops) in each direction of travel, and 8 information terminals. These terminals are equipped with a monitor and some kind of keyboard, maybe also a microphone and a small loudspeaker. The microphone and loudspeaker are for emergency use, however, and are not part of the system we are going to discuss here. These terminals are part of the booking system and the information system. They are also Bluetooth-units, with transceivers that are able to communicate with the small mobile units carried be the travelers on the platform.

Figure 1:1

3 General Situations he Bluetooth specification states that any unit can initiate a piconet communication. That unit then becomes master. Illustration 1:3 at right gives a simplified overview of the different states that a Bluetooth unit can assume. The reality is a bit more complex. For FLYWAY´s purposes, the ideal is for each of these terminals to be masters in their own piconets. In our example, the 8 terminals at the station would thus be able to serve 8 * 7 = 56 travelers at any one moment. When contact is attempted by a traveler´s unit, the terminal could be in any of 3 states: Idle, in which case it is in STANDBY-mode. Already master of a piconet with less than 7 slaves Already master of a piconet with 7 slaves	In case 1, the traveler´s unit initially assumes the role of master, since this is the unit that takes the initiative. But they quickly change roles, and for the duration of the session, the terminal is the master. In case 2, the traveler´s unit joins the existing piconet. In case 3, the terminal won´t answer. The passenger will have to move on the platform, to (hopefully) get within range of a terminal that can take on one more slave unit. Or, he can keep trying for contact at the place where he is; the waiting period before a Bluetooth terminal releases a slave and can take on a new one is usually a matter of 2-5 seconds. Generally, when manually activated by the traveler, the mobile unit will start "sniffing" for an available terminal. An "available" terminal is any terminal (within range) that has an address to spare, i.e. its quota of 7 slave units is not filled, or an idle terminal. Finding such a terminal, it will join that piconet, or start a new piconet and switch to a slave-role, as already described. It will be assigned an address by the terminal, which here will be acting as a master.	Figure 1:3

2. The Interface between Bluetooth-terminals and the FLYWAY´s Station LAN

Figure 2:1

n the FLYWAY® system, each station area has its own LAN, or Local Area Network, which, using the TCP/IP-protocol, ties all computerized units together in Ethernet-fashion. Figure 2:1 above gives a topological overview. Although the terminal and the stationary Bluetooth-unit might be physically integrated, they are individually addressed by the local LAN that they belong to, i.e. the terminal has one LAN-address, the Bluetooth-unit another address. Thus, there is no reason why Bluetooth-units could not be physically separated from the terminals, as are units 6 through 9 in the illustration. They could even be placed in nearby localities, as shown by units 8 & 9. The terminals could be placed at nearby shopping-malls and public libraries, for instance.	So, the Bluetooth units would serve the same purpose as the manual terminals; i.e. as an interface towards the travelers. Over the LAN they have contact with the station´s LAN-server, which coordinate activities at the station. Some activities are local; the server will for instance act if the same prospective passenger both tries to use a manual terminal and his Bluetooth-unit simultaneously. The server will then order the Bluetooth-unit to break off. Most activities involves the booking computer, which means that the messages have to be sent over the router to the system WAN, and on to the booking computer. Answers from this computer would then have to be relayed to the right terminal. Figure 2:2 shows how the LAN is connected to the system WAN.	Figure 2:2

3. The Interface between Passengers and Beamcars

he beamcars will also require Bluetooth-units. These units are at the other end in contact with local nodes and with the booking computer through arials mounted on the propulsion vehicles (i.e. inside the beams). Information exchange between local Bluetooth-units at a station (or at other places) and the beamcars will thus take place over several links in a rather complex chain. The information would travel from the stationary terminal to the server for the local LAN, then to the local node and/or the booking computer over the system WAN (The WAN here is the high-capacity communications network that ties the whole beam traffic system together). From the local node, the information is then carried over radiolink inside the beam to the beamcar.	The booking computer will use the WAN up to the local node, and from there on by radiolink to the car. The only stationary units that have direct access to the beamcars are thus the RF-stations connected to each node computer. This is schematically shown in figure 3:1. Given this complex chain of communication, it can easily be seen that it would be more advantageous for the travelers to be able to communicate directly with the beamcars, using their Bluetooth-units, rather than having to commandeer a car by way of the stations Bluetooth-terminals. Thus, the need for the beamcars to be equipped with Bluetooth-units.	Figure 3:1

4. The Interface between Beamcars and Station Cubicles

s has been seen, the beamcar cabins have bluetooth-units for direct passenger interface. This is necessary for those stops that do not include the FLYWAY cubicles (the cubicles are not mandatory in FLYWAY! It would, however, be logical to extend this facility to also include the doors of the station cubicles where the cabins alight, to allow passengers to enter and leave. As stated elsewhere on this site, these cubicles are meant to protect people from accidents resulting from lowering beamcabins. The cubicles thus have doors, that have to open and close in conjunction with the beamcabin doors.	This opening and closing could probably be facilitated manually, with the passengers themselves making sure that all doors are properly closed (otherwise the beamcar won´t take off). But direct Bluetooth communication between cabin and cubicle is deemed to be both simpler and more reliable to implement. So, the cubicle doors will only open and close when the cabin´s computer tells them to. And this will only happen when the right cabin is positioned in the right cubicle, and when the cabin is ready to maneuver its own doors.	Figure 4:1

5. Some Scenarios

e will here look at 4 general scenarios where the traveller has a mobile Bluetooth unit of some kind, and uses it to book a beamcar for travel with the beam network: A traveler at a station wants access to a terminal (for manually booking a beamcar, calling a beamcar or requesting information). A traveler at a station does not need physical access to the terminal. He/she only needs the terminal to relay the information sent from or requested by his mobile unit. A traveler at a station will use his Bluetooth unit to commandeer any beamcar that is already waiting. A traveler at a station will use his Bluetooth unit to commandeer a particular beamcar that is already waiting. Let´s see how these scenarios would be handled. A traveler wants manual access to a terminal´s keyboard. In this case, the travelers´ unit assumes the role of master and sends a query-message. The first terminal within range with available capacity that answers, will also notify the other terminals (over their shared LAN) that it will handle the call. After identifying the traveler´s unit and satisfying itself that the traveler has right of access, it will (if necessary) change roles with the traveler´s unit and become master. Following this, the traveler, by way of the mobile unit, indicates that he/she wants manual access to the terminal, whereupon the terminal will make itself available (by, for instance, switching on the monitor and unlocking the keyboard).

At this point, it stops functioning as a Bluetooth-unit, and becomes a regular, LAN-attached computer unit. It should be noted that a terminal in this manner can act as a master for up to 7 mobile units, while at the same time functioning as a manual terminal. As stated elsewhere, from the LAN´s point of view the manual part and the Bluetooth part are 2 different units with individual addresses, even though they are physically mounted together (see figure 2:1 above). For practical reasons, the manual LAN-terminal will only be available for one traveler at a time. It will continue to function as a Bluetooth-terminal, but if manual access to the terminal is requested, the mobile unit will be informed of the address of nearest free manual terminal, if any is available, whereupon the session terminates. Preferably, however, the mobile unit would then automatically contact this free terminal, without the traveler having to intervene. It would also be neccessary for the mobile unit to indicate on its display if that particular terminal is out of range. When such a free terminal for manual use has been contacted and made available, the mobile unit would announce to the traveler: Which terminal it is (it would be neat if the terminal itself would flash a light at the same time, to draw the traveler´s attention). A short 4-digit code, that the traveler would have to key in on the terminal. In this way, the system is reasonably assured that the right person is using the terminal.

igure 5:1 provides an example. traveler "A" puts out a call for a manual terminal. Bluetooth terminal 2 answer, since it is the nearest. It wants to assign terminal 11 to the traveler, and checks with the LAN-server if nr. 11 is free. In this example it´s not free, so the server answers in the negative, but also encloses the address of the nearest manual terminal which is free at the moment. So, the Bluetooth unit will find itself directing the mobile unit to either nr. 10 or nr. 12.

Figure 5:1

A traveler at a station does not need physical access to the terminal. This case would be handled as in the foregoing case, except that all information exchange is between the mobile unit and the Bluetooth-terminal. Depending on how the mobile unit functions, some (or all) information sent to the terminal could be pre-programmed into the unit, requiring correspondingly less intervention by the traveler. A convenient way for a traveler who does not have (or does not want to use) pre-programmed information in his unit, would be to use the unit as when sending SMS-messages over a GSM-phone.

A traveler at a station will use his unit to commandeer any beamcar that is waiting. In this case, it would be more purposefull if the mobile unit could contact the beamcar´s Bluetooth-unit directly, and not use the station´s terminals. This would be a point-to-point communication, because the mobile unit would "sniff" for a beamcar as described above, and even if more than one car responded, the mobile unit would pick only one of these, and establish a connection. The criteria for this selection could vary; the mobile unit could, for instance, pick the car with the strongest response signal, indicating that this is (probably) the nearest car. When the traveler has picked a car, the mobile unit would then ask the car to make itself available (meaning that the car migt have to lower itself to the ground and/or open its doors). Before it complies with this request, the beamcar would have to ascertain who the traveler is and that he has the right to use the requested service.

A traveler at a station will use his unit to commandeer a particular beamcar that is waiting. This case is similar to the foregoing, except that the passenger´s mobile unit would "query" for the address of the beamcar, instead of "sniffing". Only one car would thus answer (i.e. the beamcar which has the right identification), provided the car is within range. The mobile unit would then ask the car to make itself available, whereupon the car would have to check with the mobile unit who the traveler is and match his request with the information already received from the booking computer, before either opening its doors or sending some kind of message. This means that if the car has arrived at the requested address, and finds a berth free for use, it would land and wait for a specific time for the traveler to make a request for the car. But the doors of the car (and the berth, if a FLYWAY cubicle is used) would remain shut, and would not open for anyone except the right traveler. If the specified time limit expires, however, and the traveler does not appear, the beamcar would be free for use by somebody else.