anslates it to a "handover" order (hoOrd(MIN)) to the MS. There is no one-to-one correspondence between operations and events defined in the ANSI 41 protocol and the IS 136 protocol³. In situations like this, the proto- col element has to translate an event on one side to an event on the other side. For example, on one side a confirmed operation may be used, while the corresponding operation on the other side is unconfirmed. An operation on one side may require several operations in sequence on the other. The two protocols may use different operation classification systems (TCAP uses the OSI ROSE system; IS 136 opera- tions are better described by using the AML operation classification system). In a more homogeneous network environment, a protocol converter may only have to perform message relaying, see Fig. 5.46. In this hypothetical case, there is a one-to-one mapping between ASPs on both sides, maybe because the protocol net- work as a whole was defined as an AML abstract network from the beginning. The communication services used when implementing that service network may, how- ever, be different. For example, on one side of the relaying protocol element a CON-CSP is used, on the other a CNL-CSP. SDU sizes may differ as well. As a matter of fact, IS 136 does not define any operations at all. All rules are defined on the message and bit levels. The imaginary IS 136 event in the model is abstracted from that level. 5.7 Protocol Specification Methods event Message-relaying protocol element Integrator 1 Integrator 2 MT/MO MT/MO CSP1 association CSP2 association MR Message relay Fig. 5.46 A message-relaying model As a result, there may be different message handling functions performed on the two sides (formatting, encoding, and adaption functions like segmentation and error handling). Protocol Specification Methods 5.7.1 Introduction In previous sections we have seen examples of two different methods to create message formats for the message types of a protocol. In Sect. 5.4.3 we defined a general message format (