Considerando el enunciado, se entiende que el bus anteriormente estaba conformado por las

estaciones principales 2, 3 y 5. La estación 1 acaba de conectarse al bus por lo cual acaba de ser
encendida/inicializada y el token se encuentra en la estación principal 2 en ese momento. Por lo
que, antes de encenderse/inicializarse la estación 1, la estación principal con la dirección más baja
era la estación 2. Luego, se considera que las estaciones 2, 3 y 5 ya tienen su LAS y GAPL definidas
antes de encenderse/inicializarse la estación 1, por lo que debe describirse los estados por los que
pasa la estación 1.

Con esto, se describen los estados de las estaciones durante las 3 primeras rotaciones de la
siguiente manera.

1. La estación principal 1 pasa de OFF_LINE a LISTEN_TOKEN

2. La estación principal 1 espera dos rotaciones de token idénticas para generar su GAPL. Las
estaciones 2, 3 y 5 tienen sus LAS definidas de la siguiente forma

Estación Principal PS NS
1 No definido No definido
2 5 3
3 2 5
5 3 1
3. Comienza a transcurrir el tiempo de espera en el estado LISTEN_TOKEN para la estación 1.
El token pasa de la estación 2 a la estación 3 y de la 3 a la 5.
4. La estación 1 pasa a estado CLAIM_TOKEN y, a pesar de que el token pase por ella, no
puede recibirlo debido a que no tiene definida su GAPL ni su LAS.
5. La estación 1 pasa a estado PASS_TOKEN para enviar por primera vez el token para poder
obtener su LAS y su GAPL. La dirección de origen y destino es ella misma. En este pase de
Token envía tramas “Request FDL Status with Reply”.
6. La estación 1 pasa a estado de AWAIT_STATUS_RESPONSE
7. Las tramas enviadas por la estación 1 son recibidas por la estación principal 2. a lo que la
estación 2 responde con “Ready for the ring” y pasa a estado ACTIVE_IDLE. A su vez, la
estación 2 actualiza su las con PS = 1.
8. La estación 1 recibe la respuesta de la estación 2, por lo que agrega a su LAS a la estación 2
como NS
9. Las estaciones 3 y 5 responden a las tramas con “Ready for the ring” y son registradas en
el GAPL de la estación 1 debido a que respondieron después de la estación 2. De igual
manera con las estaciones secundarias responden y son agregadas al GAPL.
10. La estación 1 pasa a estado PASS TOKEN y pasa el Token con destino a la estación 2. Luego
pasa a estado CHECK_TOKEN_PASS
11. La estación 2 recibe el Token con dirección destino 2 y origen 1, lo que coincide con su TS y
PS, respectivamente. Se ejecuta su ciclo de mensajes (USE_TOKEN), actualiza su GAP y
pasa el Token a la estación 3 (PASS_TOKEN).
12. La estación 1 pasa a estado ACTIVE_IDLE debido a que el paso de Token ha sido exitoso.
13. La estación 3 recibe el Token de la estación 2 (2 pasa a estado ACTIVE_IDLE) y ejecuta su
ciclo de mensajes (3 en estado USE_TOKEN), actualiza su GAP y pasa el Token a la estación
5 (5 en estado PASS_TOKEN).
14. La estación 5 recibe el Token de la estación 3 (3 pasa a estado ACTIVE_IDLE) y ejecuta su
ciclo de mensajes (5 en estado USE_TOKEN), actualiza su GAP enviando tramas “Request
FDL Status with Reply” a lo que la estación que responde primero es la 1, por lo que la
GAPL y LAS de la estación 5 se actualiza a NS=1 y la estación 1 actualiza su PS=5. La
estación 5 pasa a PASS_TOKEN para enviar el Token a 1 y 5 pasa a estado
CHECK_TOKEN_PASS. Con esto se completa 1 rotación.

Las LAS de las estaciones ahora son:

Estación Principal P NS
S
1 5 2
2 1 3
3 2 5
5 3 1

15. La estación 1 recibe el Token de la estación 5 (5 pasa a ACTIVE_IDLE), con lo que pasa a
USE_TOKEN y Ejecuta su ciclo de mensajes. Pasa a estado PASS_TOKEN y envía el token a
2.
16. El token pasa por las estaciones 2, luego 3 y 5.
17. La estación 5 pasa el token a la estación 1. Se completan 2 rotaciones, con lo que las LAS
de cada estación no han sufrido cambios y por tanto ahora se consideran válidas.
18. La estación 1 pasa a PASS_TOKEN para enviar el token a 2, luego pasa a
CHECK_TOKEN_PASS
19. La estación 2 recibe el token (1 pasa a estado ACTIVE_IDLE) y ejecuta su ciclo de mensajes.
Luego pasa el token a 3 y ésta ejecuta su ciclo de mensajes. La estación 3 pasa el testigo a
5 y ejecuta su ciclo de mensajes. La estación 5 pasa el token a 1.
20. La estación 1 recibe el token y pasa a estado USE_TOKEN para ejecutar su ciclo de
mensajes. Se completan 3 rotaciones.