Token Bus (IEEE 802.4)
Token Bus is described in the IEEE 802.4 specification, and is a Local Area Network (LAN) in which the stations on the bus or tree form a logical ring. Each station is assigned a place in an ordered sequence, with the last station in the sequence being followed by the first, as shown below. Each station knows the address of the station to its "left" and "right" in the sequence.
A Token Bus network
This type of network, like a Token Ring network, employs a small data frame only a few bytes in size, known as a token, to grant individual stations exclusive access to the network transmission medium. Token-passing networks are deterministic in the way that they control access to the network, with each node playing an active role in the process. When a station acqires control of the token, it is allowed to transmit one or more data frames, depending on the time limit imposed by the network. When the station has finished using the token to transmit data, or the time limit has expired, it relinquishes control of the token, which is then available to the next station in the logical sequence. When the ring is initialised, the station with the highest number in the sequence has control of the token.
The physical.topology of the network is either a bus or a tree, although the order in which stations are connected to the network is not important. The network topology means that the we are essentially dealing with a broadcast network, and every frame transmitted is received by all attached stations. With the exception of broacast frames, however, frames will only be read by the station to which they are addressed, and ignored by all other stations. As the token frame is transmitted, it icarries the destination address of the next station in the logical sequence. As each individual station is powered on, it is allocated a place in the ring sequence (note that in the diagram above, station two is not participating in the ring). The Token Bus medium access control protocol allows stations to join the ring or leave the ring on an ad-hoc basis.
Token Bus networks were conceived to meet the needs of automated industrial manufacturing systems and owe much to a proposal by General Motors for a networking system to be used in their own manufacturing plants - Manufacturing Automation Protocol (MAP). Ethernet was not considered suitable for factory automation systems because of the contention-based nature of its medium access control protocol, which meant that the length of time a station might have to wait to send a frame was unpredictable. Ethernet also lacked a priority system, so there was no way to ensure that more important data would not be held up by less urgent traffic.
A token-passing system in which each station takes turns to transmit a frame was considered a better option, because if there are n stations, and each station takes T seconds to send a frame, no station has to wait longer than nT seconds to acquire the token. The ring topology of existing token-passing systems, however, was not such an attractive idea, since a break in the ring would cause a general network failure. A ring topology was also considered to be incompatible with the linear topology of assembly-line or process control systems. Token Bus was a hybrid system that provided the robustness and linearity of a bus or tree topology, whilst retaining the known worst-case performance of a token-passing medium access control method.
The transmission medium most often used for broadband Token Bus networks is 75 Ohm coaxial cable (the same type of cable used for cable TV), although alternative cabling configurations are available. Both single and dual cable systems may be used, with or without head-ends. Transmission speeds vary, with data rates of 1, 5 and 10 Mbps being common. The analogue modulation schemes that can be used include:
- Phase continuous frequency shift keying
- Phase coherent frequency shift keying
- Multilevel duobinary amplitude modulated phase shift keying
The Token Bus MAC layer protocol
When the ring is initialised, tokens are inserted into it in station address order, starting with the highest. The token itself is passed from higher to lower addresses. Once a station aquires the token, it has a fixed time period during which it may transmit frames, and the number of frames which can be transmitted by each station during this time period will depend on the length of each frame. If a station has no data to send, it simply passes the token to the next station without delay.
The Token Bus standard defines four classes of priority for traffic - 0, 2, 4, and 6 - with 6 representing the highest priority and 0 the lowest. Each station maintains four internal queues that correspond to the four priority levels. As a frame is passed down to the MAC sublayer from a higher-layer protocol, its priority level is determined, and it is assigned to the appropriate queue. When a station acquires the token, frames are transmitted from each of the four queues in strict order of priority. Each queue is allocated a specific time slot, during which frames from that queue may be transmitted. If there are no frames waiting in a particular queue, the token immediately becomes available to the next queue. If the token reaches level 0 and there are no frames waiting, it is immediately passed to the next station in the logical ring. The whole process is controlled by timers that are used to allocate time slots to each priority level. If any queue is empty, its time slot may be allocated for use by the remaining queues.
The priority scheme guarantees level 6 data a known fraction of the network bandwith, and can therefore be used to implement a real-time control system. As an example, if a network running at 10 Mbps and having fifty stations has been configured so that level 6 traffic is allocated one-third of the bandwidth, each station has a guaranteed bandwidth of 67 kbps for level 6 traffic. The available high priority bandwidth could thus be used to synchronise robots on an assembly line, or to carry one digital voice channel per station, with some bandwidth left over for control information.
The Token Bus frame format
The Token Bus frame format is shown above. The Preamble field is used to synchronise the receiver's clock. The Start Delimeter and End Delimeter fields are used to mark the start and end of the frame, and contain an analogue encoding of symbols other than 0s and 1s that cannot occur accidentally within the frame data. For this reason, a length field is not required.
The Frame Control field identifies the frame as either a data frame or a control frame. For data frames, it includes the priority level of the frame, and may also include an indicator requiring the destination station to acknowledge correct or incorrect receipt of the frame. For control frames, the field specifies the frame type.
The Destination and Source address fields contain either a 2-byte or a 6-byte hardware address for the destination and source stations respectively (a given network must use either 2-byte or 6-byte addresses consistently, not a mixture of the two). If 2-byte addresses are used, the Data Field can be up t0 8,182 bytes. If 6-byte addresses are used, it is limited to 8,174 bytes. The Checksum is used to detect transmission errors. The various control frames used are shown in the table below.
| Frame control field | Name | Meaning |
|---|---|---|
| 00000000 | Claim_token | Claim token during ring initialisation |
| 00000001 | Solicit_successor_1 | Allow stations to enter the ring |
| 00000010 | Solicit_successor_2 | Allow stations to enter the ring |
| 00000011 | Who_follows | Recover from lost token |
| 00000100 | Resolve_contention | Used when multiple stations want to enter the ring |
| 00001000 | Token | Pass the token |
| 00001100 | Set_successor | Allow stations to leave the ring |
Periodically, a station will transmit a SOLIT_SUCCESSOR frame to solicit bids from stations wishing to join the ring. The frame includes the sender's address, and that of its current successor in the ring. Only stations with an address falling between these two addresses may bid to enter the ring (in order to maintain the logical order of station addresses on the ring). If no station bids to enter within a slot time, the response window is closed, and the token holder returns to its normal business. If only one station bids to enter, it is inserted into the ring and becomes the token holder's successor. If two or more stations bid to enter, their frames will collide and be garbled. The token holder then runs an arbitration process, that begins with the broadcast of a RESOLVE_CONTENTION frame. The algorithm is a variation of binary countdown, using two bits at a time.
All station interfaces maintain two random bits which are used to delay all bids by 0, 1, 2 or 3 slot times to further reduce contention. Two stations will only collide on a bid, therefore, if the current two address bits being used are the same and they happen to have the same two random bits. To prevent stations that must wait 3 slot times from being at a permanent disadvantage, the random bits are regenerated either every time they are used, or every 50 msec.
The solicitation of new stations is not allowed to interfere with the guaranteed worst case for token rotation. Each station has a timer that is reset whenever it aquires the token. When the token arrives, the existing value of this timer (i.e. the previous token rotation time) is inspected before the timer is reset. If a pre-determined threshold value has been exceeded, recent levels of traffichave been considered to be too high, and no bids may be solicited this time round. In any case, only one station can enter the ring during each solicitation, to limit the amount of time that can be used for ring maintenance. There is no guaranteed time limit set on how long a station has to wait to enter the ring when traffic is heavy, but in practice it is not normally longer than a few seconds.
To leave the ring, a station X with a predecessor P and a successor S simply sends a SET_SUCCESSOR frame to P telling it that from now on its successor is S. Station X then just stops transmitting.
Ring initialisation is a special case of adding new stations. When the first station comes on line, it registers the fact that there is no traffic for a specified period. It then broadcasts a CLAIM_TOKEN frame. Not receiving a reply, it creates a token and sets up a ring consisting of just itself, and periodically solicits bids for new stations. As new stations are powered on, they will respond and join the ring, if necessary using the contention algorithm described above. If the first two stations are powered on simultaneously, they are allowed to bid for the token using the standard modified binary countdown algorithm and the two random bits.
Problems sometimes arise with the token or the logical ring due to transmission errors (for example a station tries to pass a token to a station which has been taken offline). After passing the token, therefore, a station monitors the network to determine wther its successor has either transmitted a frame or passed the token. If neither of these events occurs, it generates a second token. If that also fails to produce the required outcome, the station transmits a WHO_FOLLOWS frame specifying the address of its successor. When the failed station's successor sees a WHO_FOLLOWS frame naming its predecessor, it responds with a SET_SUCCESSOR frame, naming itself as the new successor. The failed station is then removed from the ring.
If two consecutive stations go offline, the WHO_FOLLOWS frame will fail to ellicit a response. In this situation, the station that originally passed the token sends a SOLICIT_SUCCESSOR_2 frame to see if any other stations are still active. The standard connection protocol is run once again, with all active stations bidding for a place until the ring is re-established. A problem can also occur if the token holder goes down and takes the frame with it. In this case, the ring initialisation algorithm is used to re-establish the ring.
Multiple tokens on the ring are another problem, and if a station currently holding a token notices a transmission from another station, it discards its token. If multiple tokens are present on the network at the same time, this process is repeated until all but one of the tokens are discarded. If all of the tokens are discarded by accident, the lack of activity will cause one or more of the stations to try and claim the token.