TMN 物理结构主要描述TMN 内的物理实体及其接口， TMN 的简化物理结构如图所示。

　　图  中OS 表示操作系统，即网管系统，是执行OSF 的系统，实际上是一种大型的管理网络 资源的系统程序；MD 表示协调设备，是执行MF 的设备，主要完成OS 与NE 间的协调功能，也能 提供QAF 和WSF，有时甚至OSF。MD 可以按分级方式实现；QA 表示Q 适配器，是完成NE 与非 TMN 接口适配互连的设备。 数据通信网DCN 是TMN 内支持DCF 的通信网，主要实现OSI 参考模型的下三层功能，而不 提供第四到第七层功能。DCN 可以由不同类型的子网，例如X.25 或DCC 等，互连而成。

　　网络单元NE 由执行NEF 的电信设备（或者是其中一部分）和支持设备组成，它可以包含其它 TMN 功能块，最常见的是包含MF。通常，NE 具备一个或多个标准Q 接口，也可以有F 接口。 工作站 WS 是执行WSF 的设备，主要完成f 参考点信息与g 参考点显式格式间的转换功能。

　　TMN 的管理层模型依照ITU-T M.3010 划分为：网元层（NEL）、网元管理层（EML）、网络管 理层（NML）、业务管理层（SML）、事务管理层（BML）。图1-24 显示了TMN 的管理层次划分。 其中，NE 可为SDH 设备，也可为PDH 或交换机等任何可被管理的设备。

　　图  TMN 管理层次

　　SDH 管理网SMN 实际就是管理SDH 网络单元的TMN 的子集。它可以细分为一系列的SDH 管 理子网SMS，这些SMS 由一系列分离的ECC 及站内数据通信链路组成，并构成整个TMN 的有机 部分。具有智能的网络单元和采用嵌入的ECC 是SMN 的重要特点，这两者的结合使TMN 信息的 传送和响应时间大大缩短，而且可以将网管功能经ECC 下载给网络单元，从而实现分布式管理。可 以说，具有强大的，有效的网络管理能力是SDH 的基本特点。

　　TMN，SMN 和SMS 的关系如图所示。 ZXSM-NMS 可以是一个SDH 管理子网SMS，也可以是一个SDH 管理网SMN，它和电信管理 网TMN 的关系如下： 如图所示，TMN 是最一般的管理网范畴，SMN 是其子集，专门负责管理SDH NE，SMN 又是由多个SMS 组成。由于ZXSM-NMS 是TMN 的一部分，它应提供标准接口接受上层网管中心 的管理。

　　在 SDH 系统内传送网管消息通道的逻辑通道为ECC，其物理通道应是DCC，它是利用SDH 再 生段开销RSOH 中D1～D3 字节和复用段开销MSOH 中D4～D12 字节组成的192kbit/s 和576kbit/s 通道，分别称为DCC（R）和DCC（M），前者可以接入中继站和端站，后者是端站间网管信息的快车道。

　　在对架构进行实现之前，首先必须清楚下一代网络管理的需求，也必须解决那些为客户带来更快更多利润的业务是如何通过相关业务执行、业务保证和计费得到支持的问题，同时还必须解决如何整合传统系统和其他资产的问题，以及传统运营机制如何向新的机制演变的问题。

　　图 基于TMN观点的架构

　　（1）管理门户

　　自顾的管理门户可能构建于内部，并通过合作的方式得到。管理解决方案供应商并不希望通过销售这种门户来赚钱，但如果没有这个门户，可能就会造成经济上的损失，因为门户看起来更像是为昨天的技术准各的。实际上，自顾的管理门户是用户进入OSS／BSS解决方案的通道。

　　门户首先通过轻量级目录接人协议（LDAP）对用户进行认证和授权，而且LDAP能够将指针指向其他管理应用，客户，业务，或者允许用户访问的网络数据。大多数的数据本身也许并不驻留在目录中，而是驻留在DBMS中。只有那些选择性较强，很少改动且被频繁访问的数据才暂留缓存在目录内，否则，目录包含的仅仅是指向真实数据的指针。

　　通过一个装有Java应用程序的网页浏览器可以访问门户，因为这些Java应用程序对于表示层是必需的。而且，通过XML技术建立的表示抽象总线允许与其他技术进行灵活的接口。因此，门户不仅可以作为设置和修改命令的通道，同时也能根据用户的授权允许用户检查业务的可用性，性能状态，业务水平，故障上报及已预定业务的计费报告等。

　　（2）应用事务处理总线

　　基于企业应用整合技术的应用事务处理总线，能够提供一种高度灵活和高度可伸缩的应用平台。许多中间件供应商具有一些固化的工作流程引擎。另外，也可以通过其他供应商的工具来开发相应的总线。然而，另外一种可能的解决方案将会使用供应商已经习惯的中间件和工作流程引擎，并可能需要建立一种包含未来管理应用的EJB总线。而且，使用基于Java的体系结构将向供应商提供一种高度灵活的，高度可伸缩的应用平台。通过EJB技术建立的应用事务处理总线支持各种与业务相关的应用的即插即用，其中的一些应用还可能访问客户和业务数据。

　　使用开放数据库互联或Java数据库互联适配器支持的对象，并通过相同的应用事务处理总线就可以访问数据。这里，数据与应用的完全分离显得非常重要，它保证了新应用对数据的访问和使用并不依赖于其他应用，从而能够将多个应用合并为一个整体的解决方案并支持应用的单独部署；而且，数据与应用的分离也帮助生产机构明确了哪些产品需要新建，哪些产品仅需要重用即可。因此，数据模型的实现将通过重用的方式进行，而应用必须具有足够的独立性。

　　（3）网络和信息技术基础设施的管理

　　在目前所描述的层次下面是经典的故障、配置、记账、性能和安全系统，也即元素管理器和网络管理器。这些管理器是系统级的，反映了物理元素所组成的网络的真实情况。信息包括用于预测额外容量的信息，用于为用法进行计费的信息或用于提供数据的信息。

　　除了现有的元素以外，网络中不断出现一些新的元素，其中一些还具有新的管理行为。大多数的元素或网络管理系统都有非常明确的目标。通常，因为元素的特性迫使其选择特定的实现方式，所以这些元素或网络管理系统能很好地服务于特定的组仵。然而，元素或网络管理系统需要有一个背向的接口，从而更加合乎标准，也将意味着接口的改变不会非常频繁，运行非常可靠并接近于实时要求。特别是对于网络管理软件供应商而言，这是一个支持业务／应用与网络和元素管理应用进行对话的内部接口.通过该接口就可以呈送特定的供给参数，收集定义完善的告警信号，性能报告和用法统计，或者是文件中收集的数据指针。

　　（4）数据模型

　　有三种主要的数据模型：客户信息模型、业务信息模型和网络信息模型。

　　①客户信息模型。客户信息模型包括与特定客户信息进行接口的数据和处理行为，如业务提供商提供的任何业务的任何用户所要捕获的所有信息，用户认证和授权信息，指向每一个客户的业务激活指针等。所有与客户相关的信息都将以逻辑数据模型的形式被保存，且能够被任何需要访问该信息的应用所访问。定义完善且容易实现的客户信息模型应该能够被所有的集成管理方案所重用，也应该只能由一个开发组织来设计和构建。

　　②业务信息模型。业务信息模型包括业务提供商提供的所有业务的定义。对特定的用户来说，需要对所有使用中的业务库和它们的当前状态进行随时的更新。每一个定义的业务都应该携带一个业务界面，以便支持SLA级别的选择。而且，业务信息模型必须考虑将SLA规格映射到QoS级别的灵活性，以及QoS级别类型和SLA规格的可扩展性。业务定义则需要考虑业务的继承性，与其他业务侧面关联性，以及创建新业务的行为支持。

　　③网络信息模型。网络信息模型需要解决所有技术驱动的网络类型问题，如网络拓扑问题，被管理元素，子网络和业务流量描述符。网络模型需要表示的其他通用数据，包括物理设各清单数据，故障处理数据，性能数据，容量数据，告警数据和路由协议数据。各种技术共存的网络域和单个网络域都需要实现网络信息模型。对于大规模的部署，需要实现模型的所有抽象类，而对于小规模部署或特定的客户市场，则仅需实现网络模型的一个子集。同样，定义完善且容易实现的网络信息模型，应该由某一个供应商开发组织来设计和构建。