, the component sublayer is neither a layer in the OSI, nor in the AMLn sense. Note also that the names of TR operations are identical to the names of TC dialogue handling operations (except for the prefix). This also indicates that the sublayer division of TC is aimed at something other than defining OSI layers (or AMLn layers for that matter). In reality, the TCAP model is an example of a frequently used method in stand- ards, that is to describe the behavior of a layer element (here the TCAP/TC ele- ment) in terms of an implementation structure, in this case consisting of an element called "component sublayer" that interworks with another element called "transac- tion sublayer." The component sublayer handles the user interface and is invisible on the network level, since the component handling operations (TC-INVOKE, etc.) do not result in any messages being sent or received. The "transaction sublayer" does send and receive TCAP messages, however, and is therefore visible on the network level. The fact that this happens through events in the user interface by TC-BEGINrequest, etc., does not alter this conception, since the component sub- layer more or less just renames primitives (e.g., TC-BEGINrequest to TR-BEGINre- quest). Thus, the two sublayers together constitute a layer element, in this case an agent of a common agent layer. By applying an artificial sublayer interface between these 6.3 TCAP, the Transaction Capability Application Part in SS7 parts (defined by TR-UNI, etc.), the TCAP inventors managed to create an unneces- sary complex model, also reflected by a complex, ASN. 1 - based TC protocol description, see ITU-T Q. 9.773. If one takes the time to interpret this document it also becomes clear that TCAP defines a single protocol since the document defines a single set of messages called "TC messages". Fortunately, supplier's actual reali- zations of TCAP normally look different from the model depicted in Fig. 6.4. TCAP can be modeled as a normal AMLn common agent layer. However, if we want to accur