 are the source for the majority of behavioral sequences in most protocols, there is no way that the ROSE parent-child concept can be used for behavior specification. If used, and if code generation is applied on ASN.1 macro that define "linked operations," only a minor part of the behavior controlling code could be generated, which most likely is worse than not generat- ing any at all. TCAP, the Transaction Capability Application Part in SS7 TCAP is a common agent layer solution that is used within ISDN and some other ITU-T public networks (e.g., in GSM). In the following eight pages you get a con- densed version of the 227 standard pages that describe TCAP, including a compari- son between how the standard describes TCAP and how the OSI RM upper layer structure and AMLn deal with the same issue. TCAP is an evolution from the ACSE, ROSE, and ASN. 1 standards of the OSI application layer. TCAP was developed to support remote operations communica- tion between layer elements of call-handling layers, which is why it is also regarded as a part of the SS7 standard (this is irrelevant to the present discussion, however). TCAP relies on the sequencing connection-less service of the SCCP layer of SS7 for its connectivity, i.e., not on the OSI presentation layer (as is the case for ACSE and ROSE). 6.3 TCAP, the Transaction Capability Application Part in SS7 A relevant question is: why did ITU-T not use its own solution for remote oper- ations and association in the OSI application layer? Part of the answer to this ques- tion was already given in previous chapters: TCAP network architects realized the misguided ambitions with the presentation and session layers when they had to ful- fill real network requirements. There were other reasons as well: 1. The intended use of TCAP was for short dialogues, often a single request to and a response from a remote actor. Considering that such dialogues were often parts of a call establishment procedure that should take a minimum of time, it was not always feasible to first establish