ontroller (TPC), 5.6 Relaying in Protocol Networks and of the five message types defined for the broadcast data-handling protocol. We can also produce formal operation specifications for the remaining nine operations of this protocol. The same procedure can then be repeated for the other protocols of the TPC. The relative complexity of the formal specifications is due to the specification technique that was used when EIA553 was designed. Although we did not modify the protocol (by mapping operations on the message formats, exactly the same messages that are described in EIA553 are created), we managed to improve its description by defining a logical node model that identifies discrimination and message-handling functions separately from other protocol networks. By using ASN.1 in combination with AML-data types, it was possible to define semantically good names for both parameters and values. An important result is that we got an abstract protocol description of the service access protocol part of EIA553. This description is considerably simpler to understand, and at the same time formal, SO that it can be used to simulate the behaviour of the TPC. If this reverse engineering effort were to be used for re-engineering as well, we would also be able to consid- erably simplify both message and operation specifications, with no extra costs in terms of bits. A less important but striking observation is also: it may be expected that the sep- aration of EIA553 into formally specified message formats and operation specifi- cations, and the use of models, would increase the descriptive overhead of information, thereby creating a still larger document than the current EIA553 pro- tocol specification. However, this is not SO. Instead, a reworked EIA553 document would decrease in size by about 50%. Relaying in Protocol Networks 5.6.1 Introduction Relaying in protocol networks should not be confused with the kind of relaying that is performed by logical networks in CSPs. The latter requires routing and switching functionality,