The FLYWAY® Communications Systems

It's better to regret something you did, than something you didn't do!

This page provides an overview of FLYWAY®´s very intricate communications. The information here is mainly graphical, and thus not too technical. The emphasis is on explaining the networks, what they do, how they function and, also, how they transfer information in between them. Details of the various networks will be provided. As of this writing, Bluetooth has been explained in detail on 2 separate pages.

Contents of this page: General The Bluetooth-based passenger interface The central LAN The station LANs The System WAN The sensor networks The beamcar RF networks.

1. General

or data communication purposes, FLYWAY® will need (at least) 6 different networks for handling the data information that has to be conveyed, and they all have to interact and transfer information in between them: The Bluetooth-based passenger interface that continually forms local virtual networks as the need arises. A Central LAN which is used for manual & automatic control, supervision, information distribution, etc. LANs that are local; one for each station and its neighborhood. The System WAN, that connects all station area LAN:s, all Node computers and all manual control centra with the Central computers (in this context, the Booking computer is of most interest). Sensor networks that are local; one for each Regional computer. They enable every local Node to keep track of the beamcars within its area. The Beamcar RF networks, that are also local to each Regional computer. As is the case with the Bluetooth networks, these are RF-based. They are inside the beams and consist physically of 2 mutually independent networks, for safety reasons.

In addition to these, provisions should be made to use the beams to provide broad-band communications for the passengers´ benefit. Access to TV- and radio channels in the cabins would be desirable. The FLYWAY® specification does not as yet include such facilities. Figure 1:1 below gives a rough idea how these communications systems are logically interconnected. The computers that need to be tied together are: The central computers that handle control, supervision, planning, security, information, etc. for the whole beam system. Some computers, manually controlled by the staff at one or more control stations. A regional computer in each administrative area. A computer at each network node. A collection of terminals at each station. A computer in each beamcar. Items 1 & 2 form the central LAN. The node computers are attached directly to the WAN.

Figure 1:1

2. The Bluetooth-based Passenger Interface

his network is described on a separate webpage. Its function is to enable travelers with mobile Bluetooth-units to communicate with the system. The system units would at such times become Masters in temporary piconets. These units will be found at 3 places: At stations, and connected to the station´s LAN. At shopping malls or anywhere else where it´s found to be convenient with such units. These would be connected to the LAN of the nearest station. On the cabins of some (or all) beamcars. These units would be connected to the beamcar´s internal computer, mounted on the car´s propulsion vehicle inside the beam. Communications Interfaces: In cases 1 & 2: as local LAN units. In case 3: to the beamcar RF network. Illustration at right shows schematically the communication routes for Bluetooth-users.

Figure 2:1

3. The Central LAN

his network is described on the webpage about Control and Supervision. This network could extend to more than one building, and for safety purposes it would be advisable that it did so. When a beam network has grown beyond a certain size, it would also be advisable to separate booking and passenger information from the other central functions, forming 2 central LANs. The data traffic volume on the net might otherwise be too heavy for the net to easily handle. This is illustrated below (figure 3:1).

Also, for beam networks beyond a certain size, it would be advisable to duplicate the whole LAN on another set of computers at another locations. This other LAN would normally run as a slave system, being constantly kept up-to-date with current information, and always ready to instantly jump into service. Communications Interfaces: Only the System WAN.

Figure 3:1

4. The Station LANs

hese are server-based Ethernet-networks that are local to each station area. By definition; in this context, a "station" are a collection of one or more berths, in close vicinity to each other, where a "berth" holds one vehicle at a time. Station areas and, where suitable, surrounding localities, are equipped with; Bluetooth transceivers Manual terminals for passengers Traffic information monitors.

Each of these are addressable units on a server-based LAN, local to the station. Communications Interfaces: At one end, the System WAN, through a router. At the other end, the 3 categories of passenger interface listed at left. Each Bluetooth transceiver is a potential Master of a Bluetooth piconet from time to time. See figure 4:1 below.

Figure 4:1

5. The System WAN

his network ties most of it together, so to speak; it is the communication backbone of the FLYWAY® system, as illustrated to the right. It provides the interface towards: The central LAN The local LANs at the stations All the node computers All the regional computers It should be pointed out here that the term "node computer" has frequently been used for the functions that belong to the regional computer. The node computer and the regional computer could physically be one and the same. They could have the same network address, or these addresses could be separate. All regional computer are also node computers. On the other hand, there would probably be node computers that do not double as regional computers. Physically, it would mostly be placed inside the beams, and preferably consist of optical fibers. The computers would gain access to the network by way of cables that are placed inside poles and other beam supports, as shown in figure 5:1. The addressing system and communications protocol would be TCP/IP. Considering how important it is, a parallell backup-system would be advisable, maybe a RF-network. The WAN has no direct connections with either the sensor networks, the beamcars nor the Bluetooth terminals. Figure 5:1

Figure 5:2

6. The Sensor Networks

The sensors are described elsewhere. Their purpose, depending on where they are placed, are 2-fold: To inform individual beamcars where they are at the moment To inform the nearest node computer where different cars are, and where they´re headed. As of this writing, their shape and exact mode of functioning has not been decided. There are other ways to solve the task assigned to these sensors. Beamcars could report their positions by other means; by using the Bluetooth communication, for instance.

Communications Interfaces: They are at one end connected to the local node computer, either in a starshaped network, where each sensor has its own connection, or addressable and connected to a bus network. They would also communicate with a corresponding sensor on each beamcar, as explained elsewhere. Considering that central supervising, booking, information and logging function also need this information, it is probably a good idea to connect these sensors directly to these computers at the network control center. The primary route for this information, however, would be from the sensor, over the node computer and then by way of the WAN to the central computers.

7. The Beamcar RF Networks

he purpose of this network is to ensure that all beamcars at all times can communicate with at least one node or regional computer. Since the cars are mobile, this means that they have to use modulated carrier waves. To solve this, there are 3 viable solutions: Using small antennas on the propulsion cars, and wave guides with a slit underneath, mounted in the ceilings of the beams. Using WLAN (Wireless LAN) technology, based on the IEEE 802.11 standard. Using Bluetooth technology, based on the IEEE 802.11 standard. Option 2 would mean a leaking field along the inside of the beam, similar to the GSM capability that has been introduced in Metro systems in many cities. Option 3 would mean placing antennas inside the beams so that a beamcar is always within communication range of at least one antenna. These stationary antennas would have to be addressable units on a bus network, and would constantly form (and break) piconets with the beamcars. If the stationary transceiver units play the role of Masters, they could each handle up to 7 beamcars at any one time.

Presumably, Bluetooth technology would work better than WLAN, considering Bluetooth´s ability to quickly and dynamically reconfigure the communicating units, as the car whiz by. Yet another solution would be to implement both options 1 & 3 as backup systems for each others, one of them playing the role of primary system. Communications Interfaces: The local node or regional computer handles all communications with beamcars in its assigned area, as explained elsewhere. In all 3 of the options above, the stationary transceiver antennas in the beams would be attached to addressable RF-units on bus networks. There can be more than one such bus for each node or regional computer. The other end would be the RF-units on each beamcar, and that unit would be connected to the beamcar´s on-board computer. The option of using Bluetooth is illustrated in figure 7:1 below. The example shows a node with 2 bus cables. Assuming that these cables were assigned numbers 3 & 5 (purely as an example!), the individual addresses of each transceiver unit could be as shown by the red digits.

Figure 7:1