ficat. (io4,io5) messages Internal External O/T/(R) integrator integrator internal association of a relay chain external eo External operation association io Internal operation Fig. 5.43 A master model that isolates external and internal interfaces The internal interfaces of the master define one side that depends on the external protocol, but is independent of the internal structure of service elements, and another side were the opposite is true. In the middle is a unit that holds the transla- tion between operations on the external and the internal sides, in terms of a transac- tion specification for each external operation. On the external side, we may have a protocol that is defined as a standardized network protocol (MAP, ISUP, etc.). The internal structure is a solution to implementing the external operations (eo) that are defined by the external protocol (although ISUP does not define explicit opera- tions, they still exist and can be abstracted out of ISUP messages). The internal structure consists of a number of service elements, C to F, which implement inter- nal operations (io). A particular implementation might not define operations either, but they exist, and can be abstracted out of internal messages. The solution structure normally depends on factors that have very little to do with which operations are defined in the external interface. To a large extent it depends on where resources are allocated in the internal structure, and on the struc- ture of the node platform on which the elements relies. Thus, in general, there is no one-to-one relation between an eo and an io. Figure 5.43 shows a scenario where the external OPH receives a request for eo1. If the request can be accepted, it is handed over to the transaction handler. The transaction specification for eo1 defines which internal service elements must be used to perform the external request, which internal operations are to be used, and in which order. In the exam- ple, the external OPH gets a request for eo1. The internal OPH will use operat