 11 decides to request something from actor 12. It generates an r-invokeOrd, that refers the actor suffix 2 as the detecting actors identity. The agent looks up its T-AL table and finds that the actor layer identifier of 11 is 1, and therefore also the actor layer to which 2 belongs. The agent then takes the actor address 12 and finds, through the T-ROa and T- RE tables, how to address the remote agent. The outgoing message contains the generating actor identity, i.e. 1. The operations of this common agent layer is rather simple, mainly because it allows only one actor per actor layer in a layer element and because it supports only simple request-reply interactions between actors. This works fine as long as all actors are always available, honest, work for free, and operate according to mutually agreed abstract protocols. In case this cannot be assumed, the common agent layer might require that an association (in TCAP referred to as a "dialogue") is first established between the actors, before they can start using r-invokes and I- invokes in their AAIs. An "association" is a communication relation between two actors that can imply a number of things: 1. The called actor will be responsive during the whole session. 2. The common-agent layer guarantees that the called actor is the one called, i.e., it belongs to the same actor layer and has the actor suffix given by the calling actor. 3. The calling actor is the one it claims to be (authentication). 4. The two actors are functionally compatible, i.e., the abstract protocol that the initiating ESM handles is supported by the other ESM as well. 5. A charging procedure has started. Associations rely on "connections" that connect common agents to each other. Associations must, however, not be confused with such connections: Associations connect actors, connections connect agents A connection between two common agents may be used for several associations simultaneously (implied by the model in Fig. 2.31) Connections are used for message transfer (an LPM activity), assoc