ed "component data," the TR user-data also tells the receiving component handler that this was initiated by a TC-BEGINrequest (for some reason coded as dialogueRequest in TR-user data), which TCAP proto- col version is referred (i.e., the version of Q.773), and which application protocol 6.3 TCAP, the Transaction Capability Application Part in SS7 the originating TC-user wants to use (coded as applContextIdentifier in TR user- data). In addition, the TC user can add an octetstring of userInfo that is not encoded by TCAP, only transported between TC users. Phase 2: Generate TR user-data For aai1 dialid agent List of components components components Component TC-user handler TC-BEGINrequest( TR user-data for aai1: destAddr, dialogueRequest applContextld. TCAPprotVersion origAddr, applContextIdentifier dialld, userInfo) userInfo componentSet Fig. 6.7 Component handling in TCAP, phase 2 When the component handler has created the TR user-data octetstring, it starts phase 3, which is when something actual happens on the network level (see Fig. 6.8). Phase 3: Send TCAP message TR user-data for aal1: dialogueRequest TCAP agent TCAPprotVersion applContextldentifier userInfo componentSet TC-user Transaction TCAP message: handler {orig Transld, TR-user data} Component handler TR-BEGINrequest T-ROa (...,destAddr, AAli,transld, TR user-data) sendSCCPOrder(destAddr{{SSN DPC} or GT), origAddr{SSN or GT}, TCAP_message_octetString) Fig. 6.8 Message handling in TCAP, phase 3. DPC=destination point code; GT=global title; SSN=subsystem number The transaction handler now starts acting. This handler, including the TR opera- tions it supports and the fact that it interfaces SCCP, shows all features of an agent, which is why we have connected it to the component handler over an internal actor-agent interface. Thus, the component handler acts as an actor in this interface 6 Applying AMLn and as an agent in interfaces to TC users (from an AMLn point of view, such ele- ments do not exist on the network level). Probably in order to uphold t