what messages look like. An actor in a connectivity layer gets user data over the AAI. It does not interpret the data. It only decides on whether to terminate the data or relay it (over the same or another AAI). An actor in a control layer takes decisions (based on information in received messages) about whether to accept the information, perform some action, and (in case) inform its peer layer elements about its actions through information in sent messages. This implies that such actors are the elements that can change the state of the layer (agents cannot, provided that they behave properly). These are the most important reasons for separating actors from agents. An actor may also handle layer interfaces to layer service users (if there are any). In most cases, standards do not define actor-agent interfaces. For example, every implementor designs his own solutions to actor-agent interfaces for TUP, ISUP, and DSS1 L3. One outstanding exception is the use of TCAP 11 agents. Fig- ure 2.15 shows a scenario of how TCAP is used in PSTN/ISDN for the IN actors SCP and SSP. Note that we call an actor that generates an event generator and the actor that handles the event detector. The identity of generators and detectors must be separated from other identifications (such as network addresses and access- point identifiers), since a layer element may include more than one actor. Layer element A Layer element B TCAP message actor agent agent actor "Tell SSP in B to release connection X" "SCP in A tells you to release connection X" where where Operation is: release Operation is: release Operation parameter is: X; type is: connection Operation parameter is: X; type is: connection Primitive type is: Order Primitive type is: Report Detector is: SSP-actor in B Generator is: SCP-actor in A Fig. 2.15 The use of TCAP in PSTN/ISDN. SCP and SSP are (derived) nodes of the IN architec- ture, not to be confused with the AMLn "control point" and "service point" The scenario shows the SCP actor ordering its agent to "tell SSP in B to rele