In the application domain of "public networks," the network structure depicted in Fig. 5.12 for the TMN management system is still too general. TMN deals with three additional problems: 1. Managing simple resources: There are always simpler network elements, such as line terminals, multiplexers, and regenerators, for which installation of an MO handling AF with a protocol stack for communication with an element man- ager, is not justifiable. TMN therefore suggests a management function, a "mediation function" (MF), that can act as an AF versus element managers, but connects a number of such resources over a some type of local communication network (LCN). This network could be a separate LAN, but also just a control channel in the traffic system part. For example, both SDH and PDH define built- in control channels to which an MF could connect. 2. Adapting existing management systems: The traffic system (or part of it) may already be managed by a non-TMN management system. It is then of interest to be able to connect that system to a common TMN system, for creating a unified management environment for some management functions and/or possibly for enhancing the range of management functions. The TMN solution is to install a special device in larger network elements, a "Q-adapter" (QAF), that can handle MOs and can act as a gateway between the mpCP network interface that the TMN system defines, and whatever network interface the existing management system defines. The QAF will translate commands and reports between the two management layers, possibly using different connectivity structures on the two sides. 3. Interworking between management systems (as indicated in Fig. 5.12): When introducing a TMN system, it does not immediately take over the management responsibility of the whole traffic system. For some time one can expect two or more MSs to manage different parts of a traffic system in parallel. One MS may even have to manage resources that are accessible only over another MS. This is a matter of shared respons