s shown by the example, a station can have several berths. And not only berths. Consider figure 3:1 above. All fairly large stations would have to look something like this, and for this system to work, each entrance need to correspond to an addressable part of the lower horizontal beam. Why is that? a beamcar coming from the left, destined for entrance 3, would just have to follow a "-L-L-R-L"-directive (L=Left, R=Right) to arrive at the right branch. Yes, but when switches come this close together, it´s theoretically possible that the car loses track of where it is. More importantly, station areas might be upgraded, adding more switches, from time to time, and upgrading of the node´s databank might not follow suit. Thus; there are 2 reasons for having addressable switches: An extra safety precaution More logical address assignments of the berths.		Reason nr. 2 will be explained in the next chapter. Thus, there would have to be one address each for the car pool (entrance 1) and the section for arriving cars (entrance 2). In this example, there are two entrances (both labeled 3) to the car buffer, so sections a and b both need individual addresses. If one wants to be able to reverse the traffic flow for this station during certain hours, then there would have to be addresses assigned also to those sections corresponding to each of the exits, since they will serve as entrances to the station when the traffic flow is reversed. So, this station would not function with just one address, it would need seven addresses. Quite possibly, one could reassign the addresses when one reverses the traffic flow, in which case this station could manage with four addresses.

Figure 3:2

s a last example of how addressing will have to be implemented, consider figure 3:2 above. Here, the berthing places are positioned parallel to each other. From the node's point of view, it would be sufficient to give one address only to each of these parallel beams 1 through 8. For the cars, however, this might not be enough. These berthing beams are intended for (in this example) four cars to load/unload simultaneously on each beam. Normally, a car would stop right behind the car in front of it. But suppose there are trucks, containers or other gear waiting at specific points along these beams! Then each such point would need an indivudual address, to enable the car to stop at this exact point. So, each of these beams, numbered 1 through 8 would need (in this example) 4 addresses in order for the cars to recognize when they have arrived. Summing up, we end up with the hierchy shown at right (figure 3:3.) The node computer is responsible for an area with many beams, here referred to as branches. Each branch can have many stations. Each station can have many entrances Each entrance can have many berths. The stations need no addresses. Branches and entrances (using the world "entrance" as in figure 3:1) are essentially the same thing, from the beamcar´s point of view.

Figure 3:3 Thus, There are 4 hierchical levels that need addresses: Networks Nodes Branches Berths. And the rest of this page will deal with the FLYWAY® system of assigning addresses to these entities.

s stated in the description of The FlyWay Guidance System, the divergence nodes could be of varying size and complexity. In this context, a node is essentially a computer, controlling the traffic on a number of nearby beams, and on one or more shunts. There would be more than one shunt for a node if the shunts are so close together that it would not be practicable to divide them on several nodes. Thus, a divergence node in the FLYWAY® concept could have several branches, each having several addressable berths. Thus, the number of addresses under a node's responsibility could become quite large. As the beam network also would be subject to alterations every now and then, it is recommended that the system for distributing addresses follow the scheme which will be detailed here.

Addressing Branches and Berths Suppose the beam network follows the 32-bit addressing scheme used on the Internet, and that a node has all of the last 8 bits at its disposal. The leftmost bits would then be used to number the branches out from the node (similar to "subnets" on the Internet) and the rightmost bits would be used to number the berths on each branch (similar to "nodes" on the Internet). How many bits should be assigned to each group? Well, that would be determined for each individual node. As can be seen from the table below, if the node for instance has 6 outgoing branches (as illustrated in the picture below), then the 3 leftmost bits in the octet would be assigned to number these branches, since it takes 3 binary bits to cover a range of 6 addresses. There would then be 5 bits left, which would be sufficient for 30 addressable berths on each branch.

he convention on Internet is that device addresses containing all zeros or all ones are reserved for special purposes, and this practice could come in handy in the beam network as well.	Therefore, these combinations should not be used for individual addresses. In the example illustrated above, there should not be any berth number 00000 or 11111 (decimal: 31). The last row in this table could apply to a node with many branches buth no berths to be responsible for.	Figure 4:2

ith this scheme, one can see (from the table above) that a node computer in the FLYWAY network could have up to 64 branches or 126 berths on any one branch, or 252 berths in total. These are upper limits to how large a node´s area could be, in terms of beam branches and berths. But this should be sufficient for any node! It should be noted that the berth address includes the branch address. As an example, take the 4:th berth on branch 3 in the illustration above. What would be its address? Well: As stated, the 3 leftmost bits would be allotted to the branch address, for this configuration. In this case, starting the count on "000", as is the convention in the computer world, the first branch (on this node) would receive binary address "000", the second "001" and the third "010". Likewise, for the berths, the first berth (on this branch) would get binary address = "00000", the 2:nd = "00001" the 3:rd = "00010" and the 4:th = "00011". Joining these 2 binary groups together, the address of this berth would be "010" and "00011", which is "01000011". As simple as that. Actually, the full network address of the berth would have to include the node address and, for very large beam networks, also the subnet-address. Assuming only one sub-network (i.e. the network is not sub-divided) with decimal address 0, and the node address being 7, "our" berth would get the following network address, in decimal notation: 0:7:2:3. A good strategy when planning the numbering of this kind of network would be to use the recommendations in RFC 1219, which actually is intended for numbering subnets on the Internet. Thus, branches should be assigned by placing binary ones only in the leftmost portion of the 8-bit address. Berth addresses should be assigned by placing binary ones in the rightmost portion of the address field. As more branches and/or berths are subsequently added to the system, the numbering should proceed from each end towards the middle of the binary address group, as shown below. Figure 4:4 By using this scheme, one gets a buffer of bits in the middle that are all zeroes. If at a later date it becomes necessary to change either of the two fields to permit more branch or berth addresses, adding additional binary bits should not require reconfiguring of the addresses already in existence.		Assigning addresses to Nodes The nodes would receive their addresses out of the 3:d byte of the 4-byte address (if you get confused, look at the overview below). As stated above, the 32-bit address field at our disposal is divided into 4 bytes of 8 bits each. The 4:th byte is used for branches and berths, as we have just discussed. The 3:rd byte is used for numbering the nodes, and, since numbers zero and 255 (the highest) should not be used for individual address assignments, this leaves us with 254 possible addresses for our nodes. Should a network grow bigger than that, we are faced with the options of: Subdividing the network, so that no area has more than 254 nodes Assigning part of the 2:nd byte in the address field as node addresses Assigning both the 2:nd and 3:rd bytes for node addressing, in which case we could have up to 2562 - 2 = 65 534 nodes. Th 2:nd option is of course the most flexible solution, and allows us to avoid the extra overhead of running a sub-divided network. By using part of the 2:nd byte, our address field would grow from 8 to 16 bits (at the most) and provide for an increasing number of nodes, as shown in the table below. Number of Bits for Node Numbering Corresponding Number of Nodes 8 254 9 510 10 1 022 11 2 046 12 4 094 13 8 190 14 16 382 15 32 766 16 65 534 Table 4:5

learly, the nodes also have to act as routers in the network, to get the cars to their destination the "best" way. Now, looking at the picture at right (figure 5:1), we have a car approaching, (at A) and announcing its destination to node 31. If the destination is 31:18, the node would handle the car as stated above. If the destination is 32:18 or 34:18, the node would find the numbers 32 or 34 in a table over its immediate neighbors, and quickly send the car instructions how to switch tracks. Or, better, the car already has a complete routing table stored in its own computer, thus reducing the required amount of intelligence exchange between beamcars and nodes. Now, suppose the car's destination is 35:18 (at B in the picture). Clearly, to be able to direct the car, node 31 must have up-to-date information about how to best reach all nodes in the network, taking into account that some beams might be temporarily blocked, closed for repair or whatever. This requires that each node also has detailed information of that nature in the areas belonging to its nearest neighbors. In the FLYWAY® concept, both nodes and beamcars are equipped with routing tables for the network, in keeping with the concept of open interfaces, and also as a backup measure in case of unreliable data communications. With "open interfaces" is meant that a "good network" should be able to service beamcars that do not have routing tables.

Figure 5:1 If the direct connection between nodes 31 and 32 is down, for instance (as shown in illustration above), the car has to be directed over node 34 to reach 32:18.

We need to consider how routers using the TCP/IP communication protocol function. Routers on the Internet often use the OSPF protocol (Open Shortest Path First) to keep each other informed about the state of the network.

OSPF is more versatile than the RIP I and RIP II protocols, and should be used when controlling the beam network traffic. It´s ideal for this purpose. In short, it functions like this:

In the TCP/IP protocol, when a router enters service, it announces its presence to the other routers in the form of a broadcast. It then receives Link State Packets (LSPs) sent by its nearest neighbor routers. These LSPs contain their routing tables, and this info enables the router to construct a routing table of its own. A router generates such a packet every 30 minutes. In addition, a change in the network causes the affected routers to transmit Link State Advertisements (LSAs) detailing the change. With this information, the routing tables can be kept up-to-date. If the network becomes so large that these routing tables become tedious for the routers to manage, the OSPF protocol enables the logical partitioning of the network into smaller areas. The routers that straddle the borders between such areas are designated as Area Boundary Routers (ABRs). These routers receive the additional task of judging which LSPs and LSAs should pass from one area to another.

Clearly, there can be two types of such areas: the Stub Area has only one ABR, which thus handles all communication with the rest of the network. The Transit Area has more than one ABR. It could thus happen that these ABRs send each other LSPs and LSAs that do not concern the other routers in this area. To enable servers in a TCP/IP-network to judge the "best" path for a packet, the OSPF-protocol includes information about: Capacity of a Link Delay factor of a Link Throughput factor of a Link Number of packets waiting for transmission on a Link Load balancing Security requirements of a Link Number of hops Thus, we have a list "made to order" for use in the beam network. You can read about how FLYWAY makes use of those criteria for routing beamcars on the page "Routing the FLYWAY Beamcars".

s mentioned above, for large networks, routing tables encompassing the whole network could theoretically become too unwieldy for the routers (or, in our case, the beam network node computers) to handle. In addition, LSPs and LSAs would generate an enormous traffic. The obvious solution is a logical partitioning of the network, as illustrated to the right. It is important to remember that this would only be an administrative arrangement and does not physically affect how the beams are connected between the network nodes. How this would work is best shown with an example. We will assume here that this particular vehicle does not have any internal routing table in its computer.

Figure 6:1

et us assume that "our" vehicle is approaching at point A. Its goal is berth 18, controlled by node 48:3, at lower right in the figure above. The vehicle announces its destination to node 41:2. This node (or, let's use the term "router" in this context!), sees from the high digits (i.e. 48) that the vehicle is just "passing through". So, our vehicle is handed over to ABR number 2, which is one of the ABRs directly connected to area 41. This choice of ABR is made from information in the routing table. The ABRs are a level higher than the routers, which only know about their areas and their nearest neighbor routers. Every ABR knows about all other ABRs and the areas they have direct access to, in the same manner that ordinary routers know about all other routers in their respective areas. So, as ABR number 2 assumes control over our vehicle, at the request of 41:2, it sees from it's routing table that ABR number 7 is the nearest ABR with direct access to area 48. It also sees the recommended rout to take, as having been reported earlier by other ABRs.

Next, possibly after a status-check with ABR 7, to ascertain that area 48 is available along it's usual routes, ABR 2 checks it's routing table for the best route, on area level. Let us say that the best route in this case would be areas 41, 42, 45 and 48, in that order. ABR 2 then sends these routing directions to our vehicle, in the form of "Left-Right-Left-Left"...etc. instructions, up to the point where the vehicle would approach the first node in area 48. Simultaneously, the pertinant part of these instructions are reported by ABR 2 to router 41:2. 41:2 has to know how the vehicle is going to turn, so that 41:2 can give the vehicle proper instructions as regards speed limits and timeslots. As the vehicle proceeds through area 41, it has to announce itself to each node as detailed earlier. It also has to tell the divergence nodes that it encounters that it already has routing instructions and what those instructions are, as far as this node is concerned. It could be that some nodes find reason to alter some of these instructions along the way, due to the traffic situation. If so, they take note of the vehicles ultimate destination area.

All nodes keep the routes to their nearets neighbors in their routing tables, even if those neighbors are in adjoining areas. Thus, our vehicle can pass on to the next area, and through it, without needing further instructions from any ABR. Likewise, when our vehicle travels along the beams belonging to areas 42 and 45, it has to inform each succeeding node where it is headed. It could also be practical to let ABR 2 provide this information to the affected nodes. All these nodes have to report back to ABR 2 as the vehicle passes. Now, something could conceivably happen somewhere on the network that would affect our car's travel route. For this reason, ABR 2 must keep a record of all vehicles currently under its responsibility. When ABR 2 is notified that something has happened, it makes a quick calculation as to which vehicles are affected and how to alter their routes. This means that ABR 2 must all the time know where those vehicles are. That's the reason why the nodes have to report the progress of the vehiclesto the ABR responsible for them.

If necessary, our vehicle thus might get new travel instructions. The new nodes that it would pass would be informed, either by the car or by ABR 2. When our car arrives at area 48, it might first encounter router number 1. Our car has now run out of routing directions and sign off with ABR 2. Then it contacts the new node (number 1) and informs it that "we" are headed for berth 48:3:18. The router sees from the highest digits of the received address (48) that this destination is within its own area. It checks its routing table and directs the car to node number 2. Node 2 likewise directs the car to node number 3. And node 3 directs the car to its berth. It should be emphasized (again) that when we use the terms "node" and "router", it is the same physical computer at the same physical place, but acting in different roles. Thus, on this final stretch of the journey, our vehicle needs the services of nodes, not of routers, to find its berth.

you have read this WEB-page this far, you will probably appreciate an overview of this matter of addressing. Refer to the 2 illustrations at right, which gives an idea how everything fits together. The upper illustration endeavours to show the 3 different addressing systems that might be needed for huge networks. For those networks that are not big enough to need logical partitioning, there would just be 2 addressing systems; the topmost alternative is for the biggest networks. The lower picture at right shows how the hierarchical addressing system functions when applied to the beam network.

Figure 7:1 Figure 7:2

Now, then, let´s have an Overview The beamcars: They should have individual 2-part identity numbers. The first part would indicate the type of car, the second part would be an inventory number. This 2-part number would also be their address when they communicate with each other and with the nodes, the routers and other computers on the beam network. The berths: They should be numbered as outlined above, according to how many numbers the branch they belong to has at its disposal. The branches: They are likewise limited in number to how many branch numbers the node they belong to has at its disposal.

The shunts: There can be many shunts to a node, and, if numbered, they would follow a separate numbering system. It could be that the shunting instruction that the car receives when approaching a node ("Left-Right-Left-Left....") are not deemed reliable enough. Then, each sensor before each shunt would tell the car, in effect, that "You're about to cross shunt number 12" or whatever. This way, the beamcar could better check that it is where it ought to be. The nodes: They would probably need two sets of addresses. a) In order to communicate with the cars, they would need addresses that logically are the same as those of the cars. Thus, they would have a 2-part address, the first part signifying them as a node, and maybe even what kind of node. b) To function as routers and nodes, they would also need addresses at the top level of the "Node-->Branch-->Berth" hierarchy, which is the addressing scheme illustrated above.

The ABR routers: If these are at all needed, they would need an extra set of addresses to talk to each other, as well as being addressed from byte 1 in the 32-bit addressing scheme. Physically, they would be identical with a few selected nodes, but functioning in another capacity. One advantage with a system as the one outlined above is that it has a built-in positioning system. The responsible node or ABR will always know where the beamcars that are temporarily in their charge really are.

An exception to pinpointing the cars' positions would be long trunk lines where the nodes are far apart. For these lines, cars beyond the booking points would just be "somewhere along". On the other hand, booking points on two converging trunk lines would be just as far away as the shortest of these lines. And after the booking points, the speed of cars would be known and their positions could be instantly calculated, since they would be moving in a time-slot.

s noted above, the OSPF-protocol allows us to give priority to some routes (and some vehicles) when deciding upon routing directions. These are evaluations that could be added to the nodes' routing tables, both manually and dynamically, as the occassions arise. In the last instance, the altered evaluations would reflect changes in the network, and be transmitted between the nodes with LSA-packets. Let's see examples of how they could be used. Capacity of a Link: Could be used to limit the size or weight of vehicles using this route. Delay factor of a Link: Could be used to tell other nodes the highest speed permitted on this route, or, rather, give the time that it would take to travel along this route. Throughput factor of a Link: Could be used to estimate the number of vehicles per time unit the the route can handle at the present (thus, a figure that could vary over time. The reason being, of course, that the route has to receive traffic from feeder beams).

Number of packets waiting for transmission on a Link: Could be used to tell other nodes that a node is overloaded and cars are queueing. Load balancing: Any suggestions? Security requirements of a Link: Could be used to indicate that certain routes are restricted to certain cars or type of cars. Maybe the routes are privately owned? Number of hops: Could be used to make some routes less attractive than other alternatives. Maybe they pass by a hospital or similar place, where one would want to keep the traffic at a minimum, so long as there are other comparable routes available. In addition to this, beamcars would have to be dynamically classified in such a manner that the nodes would take this into account and weigh it together with the information obtained through the parameters listed above. Thus, a beamcar doing ambulance service would be given highest priority during emergency transport, while, on the other end of the scale, empty cars returning to depots or going in for maintenance would be given lowest priority.