rence is that the actor identifier now identifies the remote actor that generated the LSM event. We trust that the reader has no problem with ASN.1. Otherwise, see the ITU-T recommenda- tion X.208 or some short version of it, e.g., the one given in Appendix 2 of Muth (2001). The DSS1 L3 example: How these type assignments are applied depends on the actual layer. Let's apply it to the DSS1 L3 layer. The DSS1 L3 standard does not define the actor-agent sep- aration, and therefore also no abstract protocol and no invokes (with few excep- tions, standards do not). We discussed the mapping between abstract primitives (e.g., connectRequest(...)) and the corresponding DSS1 L3 messages (e.g., SETUP) in Sect. 2.3.2.1. What we did not define, however, is how DSS1 L3 actors identify each other. In order to understand how, we must look at the connectivity structure in the DSS1 L3 layer, see the model below (details of the model in Fig. 2.6). REi (TEI) --LAPD Call- invoke DSS1 L3 Call- DSS1 L3 protocol handling handling agent (ITU-T Q.931) actor layer SAPI=0 REi (TEI) --LAPD SAPI=0 LAPD layers Call-handling logical nodes in Call-handling logical node terminals (TE) in endsystems (ES) in a local exchange (LE) Terminals (TEs) exist in endsystems (ESs), and an ES can comprise many TEs. The DSS1 L3 agent in an LE connects permanently to many ESs over LAPD link routes, using LAPD layer interfaces identified by SAPI = 0 (SAPI is the APi in LAPD). This implies that there is a single link route between the LE and each ES. Since there might exist several TEs in an ES, this route has multichannels, with each channel associated semi-permanently to a particular TE. The channel identi- fier (CHi in AMLn) is called TEI in LAPD. How these channels are distributed to individual TEs inside an ES is another story, which does not concern us in this dis- cussion. Let's now discuss which AMLn invoke parameters are needed, considering this connectivity structure: DSS1 L3 actors in TEs can only communicate with the LE actor. Furthermore, the DSS1 L