ed implementation of layer elements (in terms of block diagrams and SDL flow- charts). These diagrams were added to the two existing documents, thereby con- siderably increasing the size and complexity of the standard. 7. Erroneous use of, or interpretation of the layer concept: This comprises two issues: defining "layers" that are not layers, neither in the OSI RM nor in the AMLn sense; violating the requirement that anything inside a layer should be transparent to other layers. The most flagrant violation to the transparency requirement is the OSI presenta- tion layer and the ACSE (see the discussion in Sect. 6.2). TCAP manages to define two layers, one of which handles no messages and is therefore no layer (see Sect. 6.3). An unnecessary coupling between SCCP and TCAP is also created by letting SCCP access-point identifiers (SSNs) identify actors that are supported by 6.1 Introduction TCAP. Thus, which actor layers exist on the TCAP level is not transparent to SCCP. ATM manages to define five layers in its signaling AAL architecture (SAAL), of which only two handle protocols (see Sect. 6.4.4). MTP exhibits a rather blurred definition of the layer interface between MTP L2 and MTP L3, as already mentioned. There are many other examples of this shortage. It seems that the OSI RM-layer concept, as well as the distinction between "protocol" and "layer interface," clearly defined in the OSI RM, has not always been understood by authors of standards. 8. Integrating a traffic function and its management in a single layer: Almost with- out exception, protocol standards integrate the description of a traffic function with some management functions (often called "layer management") in the same document. From an AMLn viewpoint this is not acceptable for two rea- sons: - The time perspective for the traffic function and the management function are completely different (on-demand and as needed, respectively). - The resources on which the traffic function operates are completely different from the resources on which the corr