ately reproduce the TCAP standard, the best we can do is to map it according to the model to the right in Fig. 6.5. The generic AMLn model for common agents: AMLn model of a TCAP layer element: A layer Common agent element Mapping invokes TCAP layer element on messages Association TCAP agent TC-user handling Encoding Comp. Q.773 Q.771 handler handler TC-user T-ROa Sequencing, connection-less SCCP service Connectivity layer element (any) Ism1: Ism2: Abstract protocol Fig. 6.5 Mapping the TCAP standard on AMLn The way TCAP is specified restricts how we can model it in AMLn without redoing the standard. For example, the TCAP standard does not distinguish between the TCAP LPM and the LSMs it supports. The reason is that it uses the ROSE specification technique, which, as we saw in the previous chapter, implies that actors are regarded as integrated parts of the specification of OSI application entities, AEs (which is the way an application code generator would like to see it). The sublayer division of the TCAP agent layer is, as we already discussed, outside the scope of AMLn modeling (i.e., modeling on the network level) since communi- cation between TCAP layer elements will work whether or not they implement sublayers and TR operations. However, in order to satisfy the way the standard describes TCAP, we have included a submodel in the TCAP agent that defines two functional elements: a component handler and a transaction handler (TR handler), interconnected over an internal actor-agent interface. The only way we can explain the TCAP standard is by looking at this submodel and describe the three main phases in sending a TCAP 6 Applying AMLn message that the standard implies. The first phase stores "components" in the TCAP agent (see Fig. 6.6). "Component" is a word that does not exist in the OSI RM. It is a TCAP-unique concept that serves the purpose of supporting the way the TCAP protocol is described. Phase 1: Store and encode components TCAP agent For aai1: dialid Component List of TC-user handler components Comp