im) at the cost of two to three extra bits per OvhMessTrain. This would have been obvious if the abstract protocol level of the broadcast data-handling pro- tocol had been defined. By further investigating EIA553, we can now produce the eight operation speci- fications for operations defined by the Gaom-format. Figure 5.37 shows one of these specifications: the operation busyIdleSys. OPERATION busyldleSys::='1001'B -ACTvalue PROPERTIES ReportConfirm (BIS, $SPAR0 SIZE (15)) BIS ::= $BITSTR SIZE (1) syslsBusy BIS ::= '1'B syslsNotBusy BIS ::= '0'B COMMENT This operation is used by the network to inform MSs if the network is busy or not. An MS can access the network only if it is not busy. Fig. 5.37 One of the eight operation specifications that are supported by Gaom-messages An interesting observation with this specification is the occurrence of spare bits in an operation specification ($SPARE0 refers a bitstring where all bits are binary 0). A message format (here the format for Gaom, see Fig. 5.36) normally ensures that spare and filler bits are inserted at different points in the format, SO that map- ping between ASP information and SDUs can be made in a uniform way (in this protocol, the OvhSdu size, which must be exactly 40 bits for every message within an OvhMessTrain). However, this always costs some extra bits, which can be avoided if the spare and filler bits are defined as ASP parameters. In order to save every possible bit, all spare and filler bits are defined as ASP parameters in EIA553, differently for every ASP. Although not a good architectural principle, the stinginess of this approach might have been necessary in case of EIA553. Looking at the ASP information carried by the other message types reveals that each type carries a single ASP. As a matter of fact, there are even two types for one 5 Protocol Network Modelling single ASP, the Spom1 and Spom2. These two messages are actual fragments. Both a Spom1 and a Spom2 message are needed to carry the information of a single ASP. The four message form