that the other message types would deal with other types of MEH functions. In the ASP-carrying message type we could have expected parameters that identified the operation (OPid), primitive type (PrimType) and ASP parameters. However, EIA553 reveals that all five mes- sage types carry ASPs. The difference is instead that the mapping of ASP informa- tion on messages comprises four different formats. A rational explanation to this complicated approach is that 2-3 bits have been saved in each OvhMessTrain. This is an example of the kind of encoding optimizations that are frequently used in EIA553, which makes it impossible to use general encoding methods. Worse, how- ever, it makes the protocol difficult to understand. The only message format that defines an identifier for ASP separation is the for- mat for Gaom. The identifier is ACT and has room for 16 different ASPs, although only ten are defined SO far, see Fig. 5.36. The names of the ACT values indicates that there are actually only eight "real" ASPs, corresponding to eight C REPORT operations. The reason for, e.g. randChallA and randChallB respectively is that the Gaom message size is restricted to 24 bits, which requires fragmentation in the case of operations randChall and localControl. From an architectural point of view, it would have been better to use parameter other than ACT to control fragmentation (a TAH function), restraining ACT to identify complete ASPs only (an OPH function). 5.5 The EIA553 Case Study ACT::=$BITSTR SIZE (4) rescan ACT ::= '0001'B regIncr ACT ::= '0010'B newAccChan ACT ='0110'B accOverLoad ACT ::='1000'B busyIdleSys ACT ::='1001'B accAttempt ACT ::='1010'B randChallA ACT ::='0111'B randChallB ACT ::='1011'B localControlA ACT ::='111''B localControlB ACT ::='1111'B Gaom::-$SEQ{ac ACT, parSet ANY DEFINED BY act, END, {gaom}} Fig. 5.36 The Gaom message specification As a matter of fact, if a 1-bit fragment indicator had been added, one could have created a unified format for all ASPs (including those carried by Spom1, Spom2, Cfm and R