Read without ads and support Scribd by becoming a Scribd Premium Reader.
See Premium Plans
 
What is an Element Management System?
EMS consists of systems and applications that are concerned with managing network elements (NE)on the network element management layer (NEL) of the Telecommunication Management Networkmodel (TMN) shown below.As recommended by ITU-T, the Element Management System's key functionality is divided into fivekey areas - Fault, Configuration, Accounting, Performance and Security (FCAPS). Portions of each of the FCAPS functionality fit into the TMN models. On the northbound the EMS interfaces to NetworkManagement Systems and or Service Management Systems depending on the deployment scenario.Southbound the EMS talks to the devices.
What will be the typical feature set for an Element Management System?
The typical set of features depends on the equipment and the market it caters to. The following gridexhibits a subset of functionality prescribed by ITU-T and Telcordia for the key functional areas.
 
Fault Configuration Accounting Performance Security
AlarmhandlingAutoDiscoveryServiceUsagePerformancemonitoringPreventionAlarmcorrelationNetworkprovisioningServicelevelagreementsReportgenerationAuthenticationAlarmforwardingAuto back upand recoveryBillingDatacollection andcorrelationSystemAccessControlFiltering andFilter managementServiceActivation
Detection
LogmanagementSoftwareupgrade todevicesIntrusionrecoveryThresholdbasedreportingInventorymanagementContainmentand Recovery
 
What are the architectural challenges to be kept in mind while building an EMS? AndSuggest a suitable architecture for building an Element Management System?
In a real world situation, EV's have to cater to different market segments ranging from small ServiceProviders to large ILECs and the EMS requirements of each of these segments are different. Asimple EMS developed for a small Service Provider may not meet the scalability needs of an ILEC,while a full-featured highly available and scalable EMS that is suitable for an ILEC might be overkillfor a smaller Service Provider. Finally developing a new EMS for each segment may not be apractical or a profitable option.When confronted with the above problem, the EV's attempt to solve it by developing a basic EMSinitially and hoping that it could be scaled up to meet the demanding requirements of an ILEC. Thisstrategy definitely makes sense if the EMS is architected properly. From our experience we' venoticed that in many instances it is not the case because the initial development of the EMS is doneat the last moment and in a rushed manner. Therefore the EV's face an uphill task of scaling up theEMS. The key issue in most of these situations is that the EMS was not initially architected to meetthe requirements of large Service Providers. It is therefore essential to choose the correctarchitecture for the EMS so that it could be implemented to meet the requirements of differentsegments effectively.There are a variety of architectures that could be used to build an EMS. Based on our experience,we recommend that the EMS be developed using JEE architecture. Since JEE based applicationscould be extended to n-tiers (if required) to meet the scalability needs of the customer, we believe itis a very good fit for EMS development.The figure below shows a sample application based on JEE architecture (for more indepthinformation on JEE architecture please visit http://java.sun.com/j2ee/appmodel.html) that has fivetiers. Tier 1 is the client tier. Tier 2 is the web tier (WT). Tier 3 is the presentation tier (PT). Tier 4 isthe application tier (OT) and Tier 5 is the data tier (represented in the figure as the database).
 
Figure: JEE ArchitectureIt is important to note that boundaries between tiers are logical and is quite easily possible to run alltiers on one and the same (physical) machine. The most important thing is that the system be wellstructured, and that there is a well-planned definition of the software boundaries between thedifferent tiers. 
What are the various advantages offered by JEE Architecture for an EMS Development?
JEE architecture offers the following advantages for the development of an EMS:• When there is clear separation of user-interface-control and data presentation from application-logic, it enables more clients to have access to a wide variety of server applications. This allowsquicker development of EMS application through the reuse of pre-built components and a shortertest phase, because most often the server-components have already been tested.• Re-definition of the storage strategy won't influence the clients. In well designed systems, theclient still accesses data over a stable and well designed interface which encapsulates all the storagedetails. Even radical changes such as switching form an RDBMS to an OODBS, won't influence theclient.• Business-objects can place applications-logic or "services" on the net.• As a rule servers are "trusted" systems, data protection and security is simpler to obtain.Therefore it makes sense to run critical business processes that work with security sensitive data, onthe server.• The Database & Server tiers can be deployed in a cluster easily enhancing the scalability andavailability (a key requirement if the EMS needs to be deployed in large networks). Clusters alsoallow dynamic load balancing - if bottlenecks in terms of performance occur, the server process canbe moved to other servers at runtime.• Change management: of course it's easy - and faster - to exchange a component on the serverthan to furnish numerous PCs with new program versions.Also by the judicious use of open source technologies (where possible), the EV can reduce thedevelopment, maintenance and deployment cost of the EMS significantly while at the same timeenjoying the above-mentioned benefits. Finally since the EMS is based on a well-defined andstandardized architecture, future development and enhancement of the EMS will be easy and cost
Search
Search History:
Searching...
Result 00 of 00
00 results for result for
  • p.
    • Notes
    Load more