Fujitsu Operations Automation Using NETSMART 1500 Element Manager Paper19
User Manual: Fujitsu Operations Automation Using NETSMART 1500 Element Manager FNC Industries - Telecom Service Providers - Fujitsu United States
Open the PDF directly: View PDF 
.
Page Count: 9
| Download | |
| Open PDF In Browser | View PDF |
Operations Automation Using NETSMART 1500 Element Manager Denise Provencher (Manuscript received March 26, 2009) This paper will describe methods of automating operations processes such as network monitoring, service activation, and data collection using external interfaces available in the NETSMART 1500 Element Management System (EMS). It will describe the functions of each interface and describe the specific customer applications of these interfaces to automate manual processes. Observations regarding our experience with operations automation, particularly using standard interfaces, will be described. Finally, this paper will examine whether use of an element manager with standard or well-defined interfaces reduces the time and cost of introducing new network technologies and services. 1. Introduction Network and service providers maximize profits by reducing network operations costs and by decreasing the time required to offer new services. Expense reduction and revenue maximization can be achieved by investing in process automation. In the past, automation involved developing monolithic software systems that communicated directly with network equipment to collect alarms and provision services. Over time, the cost of developing specialized interfaces for each technology and vendor providing network equipment became prohibitive. The introduction of standardized equipment interfaces such as Simple Network Management Protocol (SNMP) and Transaction Language One (TL1) simplified alarm monitoring operations, but often had little impact on the time and cost required to support service provisioning and activation. Beginning in the late 1990s, a standard interface was defined between Element Management Systems (EMSs) and Network 422 Management Systems (NMSs) or Operations Support Systems (OSSs). The intent of this interface was to abstract network and service resources for presentation to the OSS/NMS, and to allow vendor- and technology-specific information to be managed solely by vendorsupplied EMSs (Figure 1). The EMS-NMS interface model and specification belongs to a suite of Multi-technology OSS Program (mTOP) standard interfaces from the TeleManagement Forum (TMF). The purpose of this paper is to describe how process automation is supported by the NETSMART 1500 element management system using various external interfaces; how those interfaces have been applied; and how well standard interfaces between element management layer (EML) and network management layer (NML) achieve the twin goals of reducing the time and cost of deploying new technologies and services. FUJITSU Sci. Tech. J., Vol. 45, No. 4, pp. 422–430 (October 2009) D. Provencher: Operations Automation Using NETSMART 1500 Element Manager Network management layer (NML) Network Monitoring OSS Service Activation OSS Network Monitoring OSS Service Activation OSS Standard interfaces Element management layer (EML) Element Manager Proprietary interfaces Element layer (EL) NE NE NE NE NE NE NE NE Figure 1 Non-layered and layered OSS architectures. 2. NETSMART 1500 overview The NETSMART 1500 element management system was developed by Fujitsu Network Communications in response to customer requirements for a highly scalable and highly reliable SONET network manager. When NETSMART 1500 was introduced, carriers adopted vendor-supplied management systems to supplement their OSSs. Aside from providing better tools for fault location and analysis, vendor-supplied management systems allowed new services to be offered quickly, well in advance of comparable support provided by the OSS/NMSs. The NETSMART 1500 product has evolved over the last decade to become a world-class management system for Fujitsu access and transport equipment. It provides a robust set of network management features including graphical network surveillance, end-to-end service provisioning, inventory and capacity management reporting, performance data reports, remote NE software upgrades, automated remote NE configuration backups, and a variety of “northbound” interfaces (NBIs) for integration with OSS and NMS systems. In the last few years, customers have FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009) started integrating NETSMART 1500 into their operations architecture using the TMF standard and other interfaces. 3. Northbound interface options NETSMART 1500 offers a variety of northbound interfaces (Figure 2), each of which is described below. 3.1 TL1 The TL1 northbound interface supports all management functional areas by allowing an OSS or NMS to send/receive TL1 messages to/from the network elements via NETSMART 1500. TL1 is a (primarily North American) standard ASCII message set commonly supported by transmission NEs. The NETSMART 1500 interface effectively serves as a TL1 conduit, supporting the message set over TCP/IP. The TL1 interface does not provide any abstraction to the OSS/NMS, nor does it simplify the requirements at that layer. It does, however, allow OSS/NMSs access to NEs without having to configure separate userids in each NE or use separate NE login sessions. The primary application of the TL1 interface is alarm forwarding. However, the 423 D. Provencher: Operations Automation Using NETSMART 1500 Element Manager Network management layer Fault Management Service Activation Inventory Management PM&Trend Analysis CORBA, XML, SNMP, TL1, FTP Element management layer NETSMART 1500 Network element layer SONET Data Communications Network WDM Carrier Ethernet Multiservice Packet Transport Figure 2 NETSMART 1500 northbound interfaces. interface is bidirectional, and may also be used to send provisioning commands or to retrieve performance data. 3.2 SNMP The NETSMART 1500 SNMP northbound interface sends alarms to the OSS/NMS in an SNMP format using UDP/IP. NETSMART 1500 encapsulates TL1 alarm messages in SNMP traps and sends them to one or more destinations. The SNMP interface is used exclusively for fault management, and allows popular SNMPbased OSS/NMS network surveillance products to easily monitor TL1-based transmission equipment. 3.3 MTNM CORBA The CORBA northbound interface provides the greatest functionality and the greatest complexity. Based upon the Multi-Technology Management Network (MTMN) TMF 814 interface version 2.1, it supports fault monitoring, service provisioning, inventory reporting, and 424 performance monitoring. This interface is one of the aforementioned suite of mTOP interfaces. The CORBA interface provides an abstract model for OSS/NMS applications that is particularly well suited to provisioning and service activation applications. It is based upon a simplified model of network resources, and is designed to take advantage of intelligence at the EMS and NE layers. As mentioned earlier, the intent of the MTNM interface specification is to relieve the OSS/NMS of modeling vendor-specific implementation details, and to standardize operations between the OSS/NMS layer and the EMS layer. In the MTNM interface, network equipment is modeled as a set of hierarchically named objects representing resources such as racks, shelves, slots, sub-slots, circuit packs, and SFP/XFPs. Physical connections between network elements (e.g., fibers) are modeled as Topological Links that originate and terminate on ports referred to as physical termination points (PTPs). Transmission paths, or circuits, are modeled as subnetwork FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009) D. Provencher: Operations Automation Using NETSMART 1500 Element Manager connections (SNCs) that originate and terminate on connection termination points (CTPs). There is a containment-naming relationship among termination points to model transmission layers (e.g., VT1.5 paths contained in STS1 paths). Note that this brief description is a simplification of the underlying model, but describes the essential components.1) As implemented by NETSMART 1500, the CORBA interface supports the following functions: fault event reporting, inventory retrieval, provisioning and service activation, and current and historical performance monitoring reporting. 3.4 FTP The NETSMART 1500 FTP interface provides an efficient way to collect and transfer large amounts of performance monitoring data on a periodic basis. It has been implemented in a standard fashion, as part of the TMF MTNM interface, and in a slightly simpler proprietary fashion. The standard interface allows historic PM data to be requested by an OSS/NMS using the CORBA interface. Upon receiving such request, the EMS generates a formatted file of PM data and transfers it to a location specified by the OSS/NMS using the File Transfer Protocol (FTP). The proprietary version of this interface works essentially the same way. However, the request for PM data collection and transfer is made by a human from the NETSMART 1500 GUI, and the resulting file format uses native NE naming conventions (i.e. TL1 naming conventions) rather than TMF standard names. 3.5 MTOSI XML The latest addition to the NETSMART 1500 set of northbound interfaces is an Extensible Markup Language (XML) interface based on the TMF Multi-Technology Operations System Interface (MTOSI). MTOSI, like MTNM, is part of the mTOP suite of interface specifications. The MTOSI interface uses the same network model FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009) as MTNM, but offers interfaces using Simple Object Access Protocol (SOAP) encapsulated XML documents over JMS or HTTPS. NETSMART 1500 supports two functional areas using XML: fault event reporting and inventory query and reporting. We expect to expand the functions supported by this interface as XML/SOAP has become a preferred interface for business applications, owing to its simplicity and platform independence. 4. OSS integration applications This section describes some of the key customer applications currently using one or more of the NETSMART 1500 northbound interfaces. 4.1 Carrier #1 This carrier utilizes an EMS layer in its operations architecture and has long been a proponent of TMF standard interfaces. Using the NETSMART 1500 MTNM CORBA interface, the carrier has automated fault management reporting, network discovery, and service activation operations. It also uses the FTP interface to collect PM data for all network elements on a daily basis. The carrier does not deploy new network equipment or releases until they are fully supported by the vendor’s EMS northbound interfaces. While this carrier makes extensive use of the MTNM interface, the complexity of the interface is mitigated by the following: • NETSMART 1500 EMS, the northbound interfaces, and the network equipment were introduced into the carrier’s network at the same time. • The network is limited to a single network element type. • The services provided over the network are limited in scope. On the other hand, this carrier introduced some modeling and operational concepts that previously had not been supported by NETSMART 425 D. Provencher: Operations Automation Using NETSMART 1500 Element Manager 1500. Based upon the way the carrier modeled the network and circuit inventory, NETSMART 1500 was required to manage facilities and services in a hierarchical manner, with dependencies among the layers. Further, the carrier required that NETSMART 1500 discover Optical Multiplex Sections (OMS) and report them over the MTNM interface rather than report topological links. By mutual agreement, each OMS was modeled as a subnetwork connection (SNC). Once reported to the OSS, the OMS was renamed by the OSS to serve as the fundamental SNC layer in the hierarchy of SNCs. The next layer modeled was the Optical Channel (OCH) layer, representing the end-to-end wavelength. SONET and Ethernet services were modeled as SNCs carried by the OCH layer. See Figure 3 for an example of SNC modeling implemented by this carrier.2) In this application of MTNM, the carrier’s OSS selected the route for all OCH SNCs and provided an explicit route to the NETSMART 1500 EMS as part of the SNC createAndActivate request. Routes were specified as a set of OMSs.2) The carrier also preferred non-standard naming conventions. The MTNM standard defines a fully qualified name for each object. This name is typically set by the EMS using well-defined conventions, and is guaranteed to be unique. Each object also contains the attributes “userLabel” ROADM OC48 MUX WDM and “nativeEMSName.” The intent is to use the standard name for all interface operations, and to use userLabel or nativeEMSName when interface information must be mapped to vendor identifiers or presented to a human user. A subnetwork connection is named relative to the EMS and subnetwork in which it exists (the containment relationship), with the SNC identifier being a unique name for the connection or circuit. Often the userLabel for an SNC is set by the OSS/NMS and contains a circuit identifier known to the OSS/NMS inventory system using naming conventions defined by the carrier. In the case of this customer, however, the OSS set both the SNC name and the userLabel, using the same identifier for each. Similarly, the carrier requested that equipment names not follow strict MTNM naming, but rather use a vendor-specific equipment name as the last portion (i.e. slot or sub-slot) of a fully qualified name. In this case, the vendor equipment name was the TL1 Access Identifier (AID). Thus, rather than following the MTNM convention of naming slots from right to left, numbered 1…n, we used an alphanumeric TL1 slot AID.2) The rationale for use of non-standard naming was to allow human users to easily identify objects managed by the interface, particularly when there were interface failures requiring analysis of log files. In practice, it does appear that this ROADM REGEN ILA WDM WDM ILA ILA WDM OCH107 WCH OC48 MUX OCH107 OMS OMS SNC OMS OMS SNC OMS OMS OCH SNC ODU1 WCH OC48 SNC ODU1 PTP FTP CTP ODU1 ODU1 Physical link Figure 3 SNC layers in DWDM network. 426 FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009) D. Provencher: Operations Automation Using NETSMART 1500 Element Manager convention simplifies interface operations but it requires the OSS/NMS systems to maintain vendor-specific equipment models. 4.2 Carrier #2 A second carrier deploys a multi-vendor transport network for which Fujitsu supplies a variety of equipment. This carrier had been using the NETSMART 1500 EMS for several years before initiating a multi-vendor operations automation project using the MTNM interfaces. As with Carrier #1, this carrier automated fault management reporting and service activation using the MTNM interface and it uses the FTP interface for PM data collection. Carrier #2 had a significantly more complicated network in terms of the variety of services and deployed network elements. In addition, the network had been provisioned manually for several years, necessitating a lengthy multi-phase conversion of pre-existing circuit records into MTNM subnetwork connections. This carrier maintained a hierarchical inventory of circuits and facilities, and preferred that these relationships be modeled over the interface. Since the carrier had a deployed network, several months were spent identifying the existing network configurations and circuit designs to ensure correct modeling. The following SNC layers were supported over the interface: • OMS (Optical Multiplex Section) • OCH (Optical Channel) • Line (OC192LINE, OC48LINE, etc.) • STS (STS1 or concatenated STSs) • VCAT (virtual concatenation of STSs for carrying Ethernet services) Unlike the previous carrier, this carrier’s OSS defined the route for all SNCs, including OMS layer SNCs. SNC routes other than those at the OMS layer were specified to NETSMART 1500 by listing the SNCs they were supported by. See Figure 4 for an example of how SNCs are referenced in an SNC creation request.3) FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009) The SNC hierarchy modeled in the cases of both carriers creates a dependency among SNCs. In other words, an OMS SNC must exist prior to the creation of an OCH SNC that is carried by it; an OCH SNC must exist prior to the creation of an OC48 SNC; and so forth. While there are advantages to modeling and maintaining these relationships in the EMS, it makes it difficult to migrate pre-existing circuit data. Prior to deployment of this interface, the NETSMART 1500 EMS and the carrier OSS underwent a process to convert pre-existing circuit data into SNCs. In order to properly create the layered model, SNCs at the lowest layer (i.e. OMS) were migrated first and higher layer SNCs were built on top of them. Although the carrier used welldefined conventions for designing and naming circuits, the pre-existing circuits were manually created in the OSS and contained inconsistencies that made data conversion difficult and time consuming. However, once the data was successfully converted, automated provisioning of new circuits worked well.3) Unlike Carrier #1, this carrier used the standard naming convention for managed objects. However, there were other complexities arising from the variety of circuits in the network and the way they were modeled by the OSS. The model for each of these circuit types was agreed upon between NETSMART 1500 and the OSS provider. Examples of circuit variations included non-contiguous circuits (i.e. circuits that originated and terminated on Fujitsu equipment with non-Fujitsu equipment in the middle); direct connect circuits (i.e. circuits that were supported over a logical or physical fiber connection between two NEs); and partial circuit protection. This carrier also chose to create topological links using the NBI rather than have them manually or automatically created in the EMS and reported to the OSS. Although the automation of service activation required careful planning and a number of pair-wise agreements, automation 427 D. Provencher: Operations Automation Using NETSMART 1500 Element Manager DWDM neC Transponder neB SONET neA DWDM neD OMS OCH OMS Transponder neE OMS SNC SONET neF OCH OCH SNC OC192LINE SNC OC192LINE Attribute Name userLabel forceUniqueness owner direction ProtectionLevel protectionEffort rerouteAllowed networkRouted sncType layerRate ccInclusions neTpInclusions fullRoute neTpSncExclusions zEnd aEnd OC192LINE SNCCreateData_T Structure Value DWDM/OCH/neA/neF/circuit1 FALSE CD_BI UNPROTECTED RR_NO NR_NO ST_SIMPLE 28EMS=FujitsuFederation;multiLayerSubnetwork=NETSMART1500;subnetworkConnection=ne B-to-neE-OCH TRUE EMS=FujitsuFederation;ManagedElement=neA;PTP=/Shelf=1/slot=1/port=OC192-1;CTP=/line192 ms64=1 EMS=FujitsuFederation;ManagedElement=neF;PTP=/Shelf=1/slot=1/port=OC192-1;CTP=/line192 ms64=1 additionalCreationInfo Figure 4 SNC Create Data for OC192LINE SNC. of fault reporting and PM data collection was relatively straightforward to implement and deploy. 4.3 Carrier #3 A smaller carrier with a number of regional networks has invested little in automating inventory management, service provisioning or service activation. This is probably because it has traditionally operated each region as a separate network. As this carrier centralizes decision making and strategies at the corporate level, it is beginning to focus on operations automation. The first area of automation has been fault reporting. This carrier integrated fault reporting using the NETSMART 1500 SNMP northbound interface. SNMP is the most commonly used protocol in this 428 customer segment, and easily integrates with commercially available OSS/NMS applications. In addition, it is simple to utilize and can be implemented by the customer with little or no assistance from Fujitsu. Strategically, this customer is interested in automating network inventory reconciliation using the XML-based MTOSI interface. In the near term, however, it is performing this function by exporting inventory data periodically from NETSMART 1500 and comparing it with its inventory data using simple tools. 5. Observations In general, it is easier to develop and deploy interfaces to support fault reporting and PM data collection than it is to develop and deploy FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009) D. Provencher: Operations Automation Using NETSMART 1500 Element Manager interfaces to support service activation. This is true whether TMF standard interfaces are used or not. Although service activation automation provides significant benefits in terms of reducing the time and cost of offering new services, it can require systems engineering and pairwise agreements between EMS and OSS/NMS providers. Below are specific areas of service activation automation that required particular attention in our implementation. 5.1 Network resource naming One of the benefits of the MTNM standard is that it defines a standard naming hierarchy that is descriptive without being vendor-specific. It is designed to allow OSS/NMS systems to recognize and manage network resources (e.g., slots, ports, bandwidth) and to identify them unambiguously without having to understand vendor-specific conventions. Unfortunately, it does not appear that existing OSS/NMS systems are able to take advantage of this abstraction. Our experience has been that carriers rely heavily on circuit design systems that model vendor equipment in detail. It is not clear whether this is an artifact of older operations architectures, or whether there is a need for vendor-specific information at the OSS/ NMS layer. In either case, the MTNM standard naming is not as useful as it could be, and in fact, necessitates mapping to vendor-specific models at each layer. In the case of Carrier #1, the naming was modified to better align with vendor-specific equipment names. In practice, this made it easier for users of the interface, especially when troubleshooting provisioning errors. In contrast, Carrier #2 used standard names in its inventory OSS, its service activation OSS, and over the interface. This reduced the need for mapping among systems, but made it more difficult for operations personnel to analyze error logs and resolve provisioning errors. FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009) 5.2 Circuit and facility modeling The MTNM standard allows SNC creation and activation requests to be specified in a number of ways. The options include specifying the circuit termination points (i.e. circuit source and sink) so that the EMS or the network can determine the route, or specifying each of the termination points and cross connects (used when the NMS determines the route). While it is possible to use the MTNM standard IDL to specify a circuit route by reference to one or more SNCs, as was done in our implementations, this usage was not envisioned when the standard was developed. The layered approach necessitates SNC creation dependencies, but allows the EMS to model circuits and facilities in the same way the OSS/NMS system does and allows the EMS user to see relationships among circuits. 5.3 Brownfield networks If service activation automation is introduced in a network that has been deployed for a period of time and is carrying a service (a “brownfield” network), then a data migration step may be required prior to interface activation. Data migration is necessary when the EMS is required to have a record of all existing circuits; when the SNC model differs from, or is incompatible with, other circuit models; or when the circuit model is hierarchical. The data migration phase requires that each existing circuit or facility be modeled as an SNC, imported into the EMS, and matched to existing network resources (termination points and cross connects). 6. Conclusions There is no doubt that standard interfaces are preferred over proprietary interfaces, simply because they provide a framework for interface definition and facilitate software reuse. In addition, it appears that an OSS architecture utilizing the EMS layer does reduce cost and improve efficiency when offering new services. Not only does the EMS layer insulate 429 D. Provencher: Operations Automation Using NETSMART 1500 Element Manager the OSS/NMS layer from vendor-specific interface variations, it also provides an effective means of distributing software analysis and development tasks between the carrier and the vendor. The carrier can focus on identifying new services to be offered while the vendor can focus on the requisite provisioning details. Jointly they can determine how the services are best modeled over the interface. In our experience, NETSMART 1500 support for a new NE release was commercially available at the same time the NE was available. The corresponding OSS/NMS was available slightly later and the carrier was able to deploy new services within six months of NE availability. A final advantage of utilizing an EMS layer with standard interfaces is the additional flexibility it provides to the carrier. We have seen cases where OSSs are limited in their ability to model new services cost effectively due to the age or architecture of the system. By relying on service abstraction as provided by the MTNM and MTOSI interfaces, and pushing complexity to the EMS layer, these services can be offered with the same level of automation as existing services. The TMF standard interfaces have proved they can support the technologies and services used by our customers. Based on our experience, however, the following warrant future consideration: • Use of a flat rather than layered SNC model—Use of a flat model would eliminate dependencies among SNCs that complicates both provisioning and data migration. While provisioning dependencies will exist in the network, removal of the relationship among SNCs would allow certain layers to be provisioned manually (e.g., OCH layer) so that automation can be focused on layers 430 with the greatest volume. In addition, it has the potential to simplify or obviate data migration requirements. • Use of EMS-directed or network-directed routing—While not discussed directly in this paper, a great deal of pair-wise agreements arise when the OSS/NMS provides an explicit circuit route composed of termination points and cross connects. Reliance on vendor components, whether EMS or NE, to determine circuit route and details, could simplify the interface and lead to further efficiencies. In summary, the NETSMART 1500 EMS has successfully automated operations tasks using a variety of NBIs. Fault management and performance management applications are supported easily with standard or well-defined interfaces. Service provisioning and activation applications require more effort from both carrier and vendor, but have resulted in improved operations efficiency. References 1) 2) 3) TMF814 MTNM IDL Solution Set. Version 3.5; IDL and Supporting Documents, August 2008. J. Liu: NETSMART 1500 TMF MTNM V2.1 NMI Specification. Revision 01.02, Document No. PCA-11360-DOC. V. Sethi: NETSMART 1500 TMF MTNM V2.1 NMI Specification. Revision 01.01, Document No. PCA-11359-DOC. Denise Provencher Fujitsu Network Communications Inc. Ms. Provencher received a B.S. degree in Finance from Syracuse University and worked for AT&T and Telcordia designing and developing operations support systems for North American carriers. She joined the Product Planning organization of Fujitsu Network Communications in 1996 and is currently the Director of Element Management Products, responsible for the NETSMART 1500 network management system. FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009)
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.6 Linearized : Yes Encryption : Standard V2.3 (128-bit) User Access : Print, Extract, Print high-res Tagged PDF : Yes Page Mode : UseThumbs XMP Toolkit : Adobe XMP Core 4.0-c316 44.253921, Sun Oct 01 2006 17:14:39 Instance ID : uuid:083a4e54-3a70-4262-95fa-2a290c29da69 Document ID : adobe:docid:indd:5c6a73ea-8050-11de-b2cc-e17dfe12c76d Rendition Class : proof:pdf Derived From Instance ID : 19908b6c-7b6c-11de-8cab-9e1f60aea2e4 Derived From Document ID : adobe:docid:indd:19908b6b-7b6c-11de-8cab-9e1f60aea2e4 Manifest Link Form : ReferenceStream, ReferenceStream, ReferenceStream, ReferenceStream, ReferenceStream Manifest Placed X Resolution : 72.00, 72.00, 72.00, 72.00, 300.00 Manifest Placed Y Resolution : 72.00, 72.00, 72.00, 72.00, 300.00 Manifest Placed Resolution Unit : Inches, Inches, Inches, Inches, Inches Manifest Reference Instance ID : uuid:56e0114d-e73c-4a02-9890-8880f925136b, uuid:a50d513b-7ca8-4929-b425-44727cdd8a87, uuid:3699a75c-d6b6-459c-ad4b-c816a96a153c, uuid:9d6be07f-aaac-4a38-ba42-608c0a52a410, uuid:F3AC3120DB70DE118AF0D147F024E682 Manifest Reference Document ID : uuid:CF6F2A03AA50DE11AAD8E2D2754C21A1, uuid:D56F2A03AA50DE11AAD8E2D2754C21A1, uuid:FD98F943AE50DE11AAD8E2D2754C21A1, uuid:0299F943AE50DE11AAD8E2D2754C21A1, uuid:4D44CAAE1650DE118498CD714858BDD8 Create Date : 2009:09:19 11:20:41+09:00 Modify Date : 2009:09:19 12:54:45+09:00 Metadata Date : 2009:09:19 12:54:45+09:00 Creator Tool : Adobe InDesign CS3_J (5.0.4) Thumbnail Format : JPEG Thumbnail Width : 256 Thumbnail Height : 256 Thumbnail Image : (Binary data 10264 bytes, use -b option to extract) Format : application/pdf Title : Operations Automation Using NETSMART 1500 Element Manager Creator : FSTJ Editorial Office, Fujitsu Ltd. Description : FSTJ2009-10 (VOL.45, NO.4) Producer : Adobe PDF Library 8.0 Trapped : False GTS PDFX Version : PDF/X-1:2001 GTS PDFX Conformance : PDF/X-1a:2001 Page Count : 9 Page Layout : SinglePage Subject : FSTJ2009-10 (VOL.45, NO.4) Author : FSTJ Editorial OfficeEXIF Metadata provided by EXIF.tools