r. This is not always obvious by the names selected for message types, which makes the understanding of the protocol unnecessarily difficult. You have to think in terms of ASPs and mapping ASPs on messages to see which primitive type (if any) is represented by the name of the message type. 4 Furthermore, the approach results in a larger a set of message types than ASPs. The most common reason for messages and events not corresponding one-to- one is the need for fragmentation, because the used connectivity layer does not 4 A typical example is the use of the message type SETUP in the DSS1 L3 protocol (discussed in Sect. 2.3.2.1): the same message type is used by the network for offering a call to a terminal (in which case it corresponds to a callInvite(... primitive), and by a terminal to request a service from the network (in which case it corresponds to a serviceRequest(...) primitive). The set of parameters of these two primitives are not equivalent. Since the DSS1 L3 protocol defines no ASPs, the mapping between these imaginary primitives and the SETUP message format is given through many textual comments in the DSS1 L3 protocol specification. accept unlimited size of data in a single invocation. An event may therefore be represented by a large set of messages, of the same or of different message types. Normally this should not bother event generators and detectors since the agent layer, or (better) the connectivity layer on which it relies, should perform fragmentation. This is often not so, however. As a result, the boundary between the abstract protocol and the message-protocol level becomes blurred. ASPs may have to be "fragmented", resulting in numbered operation names such as connect1, connect2, etc. This may be so even in cases when a separate agent layer is defined. For example, actor layers that rely on TCAP must consider message size limitations since TCAP runs on a non-fragmenting layer (SCCP) and does not fragment messages itself. AMLp is described in Chap. 5 of Muth (2001). Its application is diff