network address of the called party (called calledPartyNum- ber, see Fig. 2.18). RELEASECOMPLETE from the LE that informs the TE that the request cannot be fulfilled (parameters are included that tell why) CALLPROCEED from the LE that informs the TE that the request has been accepted but the call is not yet established end-to-end. SETUPACK from the LE that informs the TE that a call connection now exist end-to-end, i.e., users can start talking. In general, there is no guarantee that a message type corresponds exactly to an LSM-ASP (which is one important reason to separate LSMs from LPMs). How- ever, in the DSS1 L3 protocol there is (more or less) a one-to-one correspondence between messages and ASPs. There exist a number of ASP notations but none are standardized. We therefore use the one defined by AMLs. In AMLs, ASPs that belong to the same operation are named with the same operation name (connect here) and given a primitive type denotation that tell whether it is a request (e.g., connectReq), a confirmation of that the request is performed (e.g., connectCnf) or a refusal to perform the request (e.g., 2.3 Agents and Actors connectRef). These ASPs correspond to the messages SETUP, SETUPACK and RELEASECOMPLETE. The CALLPROCEED corresponds to an ASP that reports the actual state of the call, and is therefore denoted as the primitive type of Report of the operation callState, i.e., callStateRep. A specification of the LSM for a layer is considerably simpler, more intelligible and more valuable than a conventional protocol specification. This is because all message-handling functions are excluded, and because it gives a clear picture of the essential states and state transitions of a layer, i.e., the behavior in the layer. This picture is not blurred by the often large number of LPM states, since these are not visible to the LSM (if the LPM is correctly designed). Figure 2.25 gives an indication of how the abstract protocol for the LSM in Fig. 2.24 can be described. Terminal user callCnf(...) callReq(...) connectR